Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. iOS

iOS do princípio com Swift: Primeiros passos com UIKit

by
Difficulty:BeginnerLength:LongLanguages:
This post is part of a series called iOS From Scratch With Swift.
iOS From Scratch With Swift: Exploring the Foundation Framework
iOS From Scratch With Swift: Auto Layout Basics

Portuguese (Português) translation by David Batista (you can also view the original English article)

O UIKit é o framework que você mais irá utilizar quando desenvolver aplicativos iOS. Ele define os componentes centrais de um aplicativo iOS, como tabelas e botões para table views e navigation controllers. Neste artigo, iremos apenas começar nossa exploração pelo framework UIKit, também iremos explorar os componentes internos de um projeto iOS e o básico da construção de um aplicativo iOS.

O que é o framework UIKit?

Enquanto o framework Foundation define classes, protocolos e funções para desenvolvimento do iOS e OS X, o framework UIKit é exclusivamente orientado para o desenvolvimento iOS. Ele tem um equivalente para o desenvolvimento OS X, o framework Application Kit ou AppKit.

Como o Foundation, o UIKit define classes, protocolos, funções, tipos de dados e restrições. Ele também adiciona funcionalidades para várias classes do Foundation, tais como NSObject, NSString e NSValue através do uso das categorias do Objectve-C.

As categorias do Objective-C é uma maneira conveniente de adicionar métodos para classes existentes sem a necessidade da criação de subclasses. Eles são similares às extensões do Swift. Leia este tutorial do Aaron Crabtree se você quiser aprender mais sobre categorias do Objective-C.

Ao invés de explorar as classes principais do UIKit, como fizemos no framework Foundation, iremos criar e se aventurar por um novo projeto iOS, explorando as classes que encontrarmos. Adotando essa abordagem, rapidamente se tornará claro no contexto que a classe é usada, em como cada classe se encaixa ao esquema mais amplo de um aplicativo iOS e qual o papel que ela desempenha.

Um novo começo

Inicie o Xcode e crie um novo projeto selecionando New > Project... no menu File. Na seção iOS na esquerda, selecione a categoria Application. Na lista de templates de projeto, escolha o template Single View Application.

O template Single View Application contém o básico para a construção de um aplicativo iOS, o que o torna o melhor lugar para começarmos nossa jornada.

Choosing a Project Template

Chame seu projeto de FirstSteps e entre com um organization name e identifier. Defina a Language como Swift e defina Devices como iPhone. Deixe desmarcada as caixas de seleção na parte inferior.

Configuring the Project

Diga ao Xcode onde você deseja salvar o novo projeto e certifique-se de colocar o projeto sob controle de versão, marcando a caixa de seleção Create Git repository on My Mac. Revisite este artigo para mais informações sobre o controle de versão e seus benefícios.

Saving the Project

Arquivos e pastas

Nós aprendemos muitas coisas novas desde a última vez que criamos um projeto iOS do zero, então é uma boa ideia explorar os vários arquivos e pastas do nosso novo projeto para ver se eles conseguem nos relembrar algo.

No Project Navigator, você poderá ver duas pastas na raiz do projeto.

  • Products
  • Uma pasta com o nome do seu projeto, FirstSteps neste exemplo.

Dê uma olhada no conteúdo de cada uma dessas pastas.

Project Structure

Products

A pasta Products tem atualmente um item. Ele tem o nome do projeto e uma extensão .app. A pasta Products contém o aplicativo - ou aplicativos - criados pelo projeto após a compilação do código fonte.

Você percebeu que o FirstSteps.app está marcado com vermelho? Se o Xcode não encontrar o arquivo em seu local, ele marcará o arquivo em vermelho. Não se preocupe com isso. Como o projeto ainda não foi compilado, o Xcode não criou o produto ainda.

Pasta Project

A maioria de seu tempo é gasto na pasta do projeto, que atualmente contém seis arquivos. Os dois primeiros arquivos, AppDelegate.swift e ViewController.swift são arquivos fontes. Esses arquivos contêm o código fonte do aplicativo.

O Main.storyboard contém a interface do aplicativo. Já trabalhamos com storyboards anteriormente nesta série. Note que há um segundo storyboard, LaunchScreen.storyboard. Este storyboard é usando pelo sistema operacional quando o aplicativo é iniciado. Ao invés de mostrar uma tela em branco, o sistema operacional usa este storyboard para criar dinamicamente uma imagem inicial, que é mostrada ao usuário quando o aplicativo é carregado.

O Info.plist, geralmente referenciado como arquivo "info-dot-plist" do projeto, é uma lista de propriedades que contém várias configurações. A maioria dessas configurações também podem ser modificadas selecionando o projeto no Project Navigator, escolhendo o target na lista Targets e abrindo as abas General, Capabilities e Info.

O Assets.xcassets é um tipo especial de pasta para armazenar os recursos do seu projeto, tais como imagens

Componentes do aplicativo

Agora que sabemos o que os diferentes arquivos e pastas são no nosso projeto, é hora de explorar os diferentes componentes de um aplicativo iOS. A medida que continuamos nossa jogada, vamos nos deparar com varias classes que pertencem ao UIKit.  As classes que pertencem ao framework UIKit começam com o prefixo UI. Lembre-se que as classes Foundation são prefixadas com NS.

O padrão Model-View-Controller

Antes de iniciarmos nossa exploração pelo framework UIKit, eu quero falar sobre o padrão Model-View-Controller (MVC). O padrão MVC é um dos mais difundidos padrões na programação orientada a objetos. Ele promove a reusabilidade de código e mantém relações próximas com o conceito de separação de responsabilidades ou interesses. O principal objetivo do padrão MVC é a separação da lógica de negocio da camada de apresentação do aplicativo.

O Cocoa Touch adota o padrão MVC, o que significa que é importante entender o que é e como ele trabalha. Em outras palavras, entendendo o padrão MVC, ficará fácil compreender como os diferentes componentes de um aplicativo iOS funciona.

No padrão MVC, a camada model está no controle da lógica de negocio de um aplicativo. Interagir com uma base de dados, por exemplo, é a responsabilidade da camada model. A camada view apresenta os dados que é administrado pala camada model para o usuário. A camada view administra a interface e as ações do usuário.

A controller é a cola entre a camada model e a camada view. Enquanto a camada model e a camada view não sabem sobre a existência uma da outra, a controller sabe sobre ambas.

Como a controller sabe sobre a model e a view, frequentemente ela é a peça menos reusável de um aplicativo. Quanto menos um objeto conhece sobre seu ambiente e os objetos interagindo com ele, mais fácil de reusa-lo.

UIApplication

Apesar de a classe UIApplication ser o componente principal de todo aplicativo iOS, você não irá interagir com ele frequentemente e você raramente, ou nunca, vai sentir que precisa da subclasse UIApplication.

Quando um aplicativo inicia, um singleton desta classe é criado. Você se lembra o que é um objeto singleton? Isso significa que apenas um objeto de instância da classe UIApplication é criada durante o tempo de vida do aplicativo.

A instância UIApplication é o ponto de entrada para o usuário interagir ou disparar eventos do objeto alvo apropiado. O significado exato disto ficará claro em alguns minutos, quando dermos uma olhada nas view controllers.

Em aplicativos iOS, a instância UIApplication tem um objeto delegado associado a ele. Sempre que você criar um projeto iOS usando um dos templates disponiveis, o Xcode criará uma classe application delegate para você. Dê uma olhada nos nomes dos arquivos fontes na pasta do projeto no Project Navigator. O primeiro arquivo é chamada de AppDelegate.swift.

A instância desta classe é um delegado do singleton UIApplication. Antes de analisar profundamente a classe AppDelegate, precisamos entender o que é o padrão de projeto delegate.

Ole Begemann escreveu um excelente artigo sobre a sequencia de inicialização de um aplicativo iOS comum. No artigo dele, Ole fala sobre os vários componentes envolvidos e suas funções durante a sequencia de inicialização do aplicativo. Eu realmente recomendo a leitura deste artigo se você quer ter um melhor entendimento da função da classe UIApplication.

O padrão Delegate

O padrão delegate é consideravelmente usado no Cocoa e Cocoa Touch. Em um artigo futuro desta série, em que exploraremos as entradas e saídas das table views, você descobrirá que as table views dependem muito do padrão delegate (e data source).

Como o padrão MVC, delegação é comum em programação orientada a objetos. O padrão delegate em Cocoa Touch, entretanto, é um pouco diferente, por que ele faz uso de um protocolo delegado para definir os comportamentos do objeto delegado.

Vamos dar um passo a frente e dar uma olhada nas table views Se você utilizou um iPhone ou iPad por algum tempo, então já deve ter conhecido a classe UITableView. Ela apresenta uma lista ordenada de dados para seu usuário e ela faz esse trabalho muito bem.

Como uma table view sabe o que deve fazer quando uma linha e tocada? Este comportamento é incluido na classe UITableView? Certamente não, por que este comportamento vária de aplicativo para aplicativo. Se incluirmos este comportamento na classe UITableView, ele não será muito reutilizável.

A table view terceiriza esta responsabilidade para o objeto delegado. Em outras palavras, ele delega esta função a outro objeto, um objeto delegado. Tire um tempo para verificar o guia de referência da classe UITableView. Ela tem duas propriedades chamada dataSource e delegate. O delegate é notificado pela table view quando o usuário toca em uma linha. É responsabilidade do objeto delegado responder a este evento de toque.

O data source da table view é similar. A principal diferença é que a table view pede ao objeto data source por algo, o dado que ele precisa mostrar.

Objetos delegados e data source, tais como objetos delegate e dataSource da table view, são quase sempre classes personalizadas. Na maioria dos casos, é função do desenvolvedor criar e implementar estas classes, pois sua implementação é especifica para cada aplicativo.

O Application Delegate

Agora que você sabe o que é delegação, é hora de explorar a classe AppDelegate que o Xcode criou para nós. Durante a inicialização do aplicativo, o aplicativo cria uma instância da classe AppDelegate. Esta instância do AppDelegate é então definida como o delegado da instância UIApplication que o sistema operacional cria para seu aplicativo. Você nunca instância um objeto application delegate.

Abra o AppDelegate.swift para examinar a implementação da classe AppDelegate. Ignorando os comentários no topo, a primeira linha importa o framework UIKit para que possamos trabalhar com suas classes e protocolos.

Na linha seguinte, vemos algo que não cobrimos ainda, um atributo. Atributos em Swift começam com um simbolo @ e podem ser vistos como instruções para o compilador. O atributo @UIApplicationMain diz ao compilador que o AppDelegate é uma classe que deve ser usado como o delegado do aplicativo. Isso é tudo que você precisar saber sobre este atributo por enquanto.

A linha seguinte você conhece. Este é o começo da declaração da classe AppDelegate. Ele especifica o nome da classe e sua classe pai, UIResponder.

Ele também informa ao compilador que o AppDelegate está em conformidade com o protocolo UIApplicationDelegate. Isso não é surpresa já que sabemos que o AppDelegate serve como o delegado do aplicativo.

A linha seguinte é uma declaração da propriedade para a propriedade window. Note que a propriedade é uma variável do tipo UIWindow?. A classe UIWindow é uma subclasse da UIView, a classe base para views no iOS.

A parte mais interessante da interface da classe AppDelegate é o protocolo UIApplicationDelegate. Dê uma olhada no guia de referência do protocolo UIApplicationDelegate para uma lista completa dos métodos que o protocolo define.

O protocolo define dezenas de métodos e eu encorajo você a explorar alguns deles para ter uma idéia das capacidades do protocolo. O método mais interessante para nós neste ponto é o application(_:didFinishLaunchingWithOptions:).

Quando o objeto UIApplication termina a preparação do aplicativo para inicia-lo, ele notifica seu delegado, o objeto AppDelegate, que o aplicativo está prestes a ser iniciado.

Por que notificar o delegado do aplicativo deste evento? A instância UIApplication notifica seu delegado sobre este evento para que ele tenha a oportunidade de preparar o aplicativo para inicializar. A implementação do application(_:didFinishLaunchingWithOptions:) é muito curta, como você pode ver abaixo.

Ele recebe uma referencia para a instância UIApplication e um dicionário de opções. Você pode ignorar o dicionário de opções por enquanto. Para garantir que o aplicativo será inicializado pelo sistema operacional, retornamos true.

Storyboard

O projeto Xcode contém outro arquivo interessante, Main.storyboard. O storyboard define como será a interface do seu aplicativo. Por padrão, o storyboard se chama Main.storyboard. Selecione o storyboard para abri-lo.

The Main Storyboard of the Project

O storyboard atualmente contém uma view no centro da área de trabalho. Na esquerda do Project Navigator você pode ver uma lista de itens, que são os objetos que você vê na view. O item do topo, View Controller Scene, contém um item filho, View Controller.

O objeto View Controller também tem alguns itens filhos, mas há um que é especialmente interessante para nós, o objeto chamado View. Lembra-se que discutimos sobre o padrão MVC. Você pode ver agora o padrão MVC em ação. O model não existe no momento, mas temos uma view, o objeto View, e um controller, o objeto View Controller.

Quando o aplicativo inicia, o storyboard é usado para criar a interface do aplicativo. A view controller é automaticamente instanciada e assim a view da view controller. O objeto View no storyboard é gerenciado pela view controller.

Espere um minuto. Onde posso encontrar a classe da view controller no storyboard? Como eu posso mudar esse comportamento para ciar um aplicativo único? Seleciona o objeto View Controller na esquerda e abra o Identify Inspector na direita.

The Class of the View Controller

O Identify Inspector te informa tudo que precisa saber. No topo, na seção Custom Class, você pode ver o nome da classe da view controller, ViewController. Você percebe que o arquivo que falamos ainda a pouco tem o mesmo nome? Vamos explorar este arquivo em alguns instantes.

A view controller é instanciada para nós, porque ela é a view controller inicial do storyboard. Isto é indicado no storyboard por uma flecha apontando para a View Controller Scene.

The arrow points to the initial view controller of the storyboard

UIViewController

Se você abrir o arquivo ViewController.swift, você ira perceber que a classe ViewController é uma subclasse da UIViewController. Como o AppDelegate, a classe UIViewController é uma subclasse da UIResponder. As view controllers, ou suas subclasses, caem na categoria controller do padrão MVC. Como o nome já diz, eles controlam uma view, uma instância da classe UIView, que pertencem a categoria view do padrão MVC.

Com vimos anteriormente, uma view controller gerencia uma view e suas subview. Para fazer isso, a view controller precisa saber sobre a view. Em outra palavras, ela precisa ter uma referência da view.

A view controller no storyboard tem uma referência para a view. Você pode verificar isso selecionando a view controller no storyboard e abrindo a Connections Inspector na direita.

The view controller has a reference to its view

Na Connections Inspector, você verá uma seção chamada Outlets. O termo outlet é um apelido para uma propriedade que você pode definir no storyboard. Siga com o mouse sobre o outlet chamado view e observe como a view do workspace se destaca. Esta é a conexão entre a view controller e a view.

UIView

Apesar do seu aplicativo poder ter apenas uma instância da UIWindow, ele pode ter muitas views. A classe UIView é um componente importante do framework UIKit, porque muitas classes são herdeiras dela - diretamente ou indiretamente.

Revisite o arquivo Main.storyboard selecionando ele e dê uma olhada no Object Library na parte inferior da Inspector.

Browsing the Object Library

Navegue no Object Library e arraste um label e um button para a view na área de trabalho. Não importa onde você os posicione na view, desde que eles estejam na view da view controller.

Adding a Label and a Button to the Storyboard

Note que dois novos objetos foram adicionar na seção Objects na esquerda. Ambos, a label (UILabel) e o botão (UIButton) herdam da UIView. Você percebeu que os objetos Label e Button estão ligeiramente recuados comparados ao objeto View? Isso indica que os objetos Label e Button são subviews do objeto View. Uma view pode ter uma ou mais subview gerenciadas por ela.

Como eu mencionei anteriormente, a classe UIView é um componente importante do UIKit. Uma view gerência uma área retangular ou uma quadro na tela. Ela gerência o conteúdo da área, as subviews e qualquer interação com o conteúdo da view. A classe UIView é uma subclasse da UIResponder. Você aprenderá muito mais sobre views no decorrer desta série.

Outlets

Vamos dar uma olhada em um exemplo para ilustrar o relacionamento entre o storyboard, a view que ele contém e a view controller. Esses três componentes são importantes e eu quero certificar que você entenda como eles funcionam juntos.

A alguns momentos atrás, você adicionou uma label e um botão á view da view controller. Como fazer a view controller saber sobre estes objetos? Neste momento, eles não aparecem na Connections Inspector, mas vamos mudar isso informando a view controller sobre eles. Abra o arquivo ViewController.swift e adicione uma propriedade para a label e uma para o botão.

Adicionando o atributo @IBOutlet à declaração da propriedade, a propriedade aparece na Connections Inspector no storyboard e é isso o que queremos.

Volte ao storyboard, selecione o objeto View Controller na View Controller Scene e abra a Connections Inspector na direita. As novas propriedades estão agora listadas na lista de Outlets. Entretanto, a view controller não fez a conexão entre as novas propriedades e os objetos na storyboard.

Isso é fácil de resolver. Arraste o mouse do circulo vazio a direita da outlet myLabel para a label da área de trabalho. Isso criará a conexão. A view controller agora sabe sobre a label. Repita o passo para o botão.

Connecting Outlets in the Storyboard

Mesmo que possamos alterar o texto do label no storyboard, vamos fazer isso na view controller para demonstrar que a view controller tem acesso ao label e ao botão do storyboard.

Abra o arquivo ViewController.swift e vá no método viewDidLoad(). Altere o método viewDidLoad() para refletir a implementação abaixo. Os comentários foram removidos para facilitar.

Podemos enviar mensagens para a propriedade label acessando a propriedade myLabel da View Controller. Podemos alterar o texto da label ajustando a propriedade text da label, usando uma string literal.

O método viewDidLoad() é chamado automaticamente quando a view controller for carregada pela sua view. A palavra chave override indica que estamos sobrepondo um método que foi definido por uma classe superior na árvore hierárquica. A classe UIViewController, a classe pai da classe ViewController, implementa este método.

Note também que chamamos o viewDidLoar() no super. O que é super? Como o self se refere á instância corrente, o super se refere a classe pai, UIViewController. Em outras palavras, chamamos o método viewDidLoad() da superclasse. Isto é muitas vezes importante ao substituir um método em uma subclasse, porque a superclasse pode realizar tarefas importantes em sua própria implementação e não queremos perder nada.

Execute seu aplicativo no simulador clicando no botão Run na parte superior esquerda. Note que o texto da label foi atualizado. Não se preocupe com a posição do label e do botão. Isso é algo que vamos corrigir no próximo tutorial.

Actions

Exploramos algumas coisas novas neste artigo. Eu quero finalizar este capítulo falando sobre actions. Como os outlets, actions nada mais são do que métodos que você pode acessar pelo storyboard.

Vamos ver como isso trabalha. Abra o arquivo ViewController.swift e adicione o método a seguir abaixo do método viewDidLoad().

Não precisa ficar confuso com o atributo @IBAction. Este atributo indica que o método é uma action e, entretanto, acessivel pelo storyboard. Se olharmos mais a fundo a action changeColor(_:), podemos ver que ela recebe um argumento do tipo UIButton.

Como o nome do argumento indica, o argumento do método ou action é o objeto que envia a mensagem da view controller. Eu explicarei isso com mais detalhes em alguns instantes.

Revisite o storyboard, selecione o objeto View Controller na View Controller Scene e abra o Connections Inspector. Uma nova seção terá aparecido na Connections Inspector, Received Actions, e a ação que adicionamos estará listada nesta seção.

Connecting the Action in the Storyboard

Arraste do circulo vazio á direita da action para o botão na área de trabalho. Um menu com uma lista de opções irá aparecer. A lista contém todos os possíveis eventos que o botão pode responder. O que nós interessa é o Touch Up Insite. Esse evento é ativado quando o usuário toca no botão e tira o dedo dentro dos limites do botão.

Choosing the Appropriate Touch Event

Rode seu aplicativo mais uma vez e toque no botão. A view da view controller irá trocar de cor toda vez que você tocar no botão. Adicionamos duas novas instruções de print na action changeColor(_:). Vamos ver o que aparece na saída quando você toca no botão.

A primeira linha mostra a classe do emissor, uma instância da UIButton. Isto prova que é o botão que está ativando esse método da view controller. Ele está enviando uma mensagem da changeColor(_:) para a view controller.

A segunda linha mostra a superclasse do emissor. Lembre-se que nem toda classe tem uma superclasse. Por essa razão que recebemos um opcional. A saída nos diz que a classe pai da UIButton é UIControl.

O método sem si é muito simples. Geramos três inteiros aleatórios entre 0 e 255, passamos estes valores para init(red:green:blue:alpha:) para gerar uma cor aleatória e atualizamos a cor de fundo da view da view controller com a cor gerada aleatoriamente. Observe que a view referencia a view que a view controller gerencia.

Conclusão

Neste artigo, exploramos algumas classes do framework UIKit e nos aprofundamos em vários componentes de um aplicativo iOS. Iremos explorar e trabalhar com o framework UIKit com mais detalhes no restante desta série. Se você não entender completamente os vários conceitos e padrões, eu tenho certeza que você irá entender com o progresso da série.

Se você tiver alguma pergunta ou comentário, você pode deixa-los nos comentários abaixo ou me procurar no Twitter.

Seja o primeiro a saber sobre novas traduções–siga @tutsplus_pt no Twitter!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.