Grand Central Dispatch: Para ajudá-lo a abstrair a execução de peças de trabalho.

Você
pode agendar o código para ser executado sequencialmente em uma fila serial ou
executar várias tarefas simultaneamente em diferentes filas com diferentes
prioridades.
• Closures: Para criar trechos de código separados que você pode passar em seu
código, para que outros objetos possam decidir se devem executá-lo ou não, quantas
vezes e em que contexto.
Como a maior parte do seu código típico realizaria algum trabalho de forma assíncrona
e todos os eventos de interface do usuário são inerentemente assíncronos, é
impossível fazer suposições em que ordem todo o código do seu aplicativo será
executado.
Afinal, o código do seu aplicativo é executado de forma diferente dependendo de
vários fatores externos, como entrada do usuário, atividade de rede ou outros eventos
do SO. Cada vez que o usuário inicia seu aplicativo, o código pode ser executado em
uma ordem completamente diferente, dependendo desses fatores externos. (Bem,
exceto no caso em que você tem um exército de robôs testando seu aplicativo, então
você pode esperar que todos os eventos aconteçam com sincronização precisa de kill-
bot.)
Definitivamente, não estamos dizendo que escrever um bom código assíncrono é
impossível. Afinal, as ótimas APIs da Apple listadas acima são muito avançadas, muito
especializadas para a tarefa e, para ser justo, bastante poderosas em comparação com
o que outras plataformas oferecem.
O problema é que código assíncrono complexo se torna muito difícil de escrever em
parte devido à variedade de APIs que o SDK da Apple oferece:
O uso de delegados exige que você adote um padrão específico, outro para
encerramentos, outra abordagem para assinar o NotificationCenter e assim por diante.
Como não existe uma linguagem universal em todas as APIs assíncronas, ler e entender
o código e raciocinar sobre sua execução se torna difícil.
Para encerrar esta seção e colocar a discussão em um pouco mais de contexto, você
comparará duas partes de código: uma síncrona e outra assíncrona.
26. raywenderlich. com
RxSwift - Programação reativa com Swift Capítulo 1: Olá, RxSwift! Código síncrono
Executar uma operação para cada elemento de um array é algo que você já fez muitas
vezes. É um bloco de construção muito simples, mas sólido, da lógica do aplicativo
porque garante duas coisas: ele é executado de forma síncrona e a coleção é imutável
enquanto você itera sobre ela.
Tome um momento para pensar sobre o que isso implica. Ao iterar sobre uma coleção,
você não precisa verificar se todos os elementos ainda estão lá e não precisa
retroceder caso outro thread insira um elemento no início da coleção. Você supõe que
sempre itera sobre a coleção em sua totalidade no início do loop.
Se você quiser brincar um pouco mais com esses aspectos do loop for, tente isso em
um playground:
A matriz é mutável dentro do corpo for? A coleção sobre a qual o loop itera muda?
Qual é a sequência de execução de todos os comandos? Você pode modificar o
número se precisar?
Código assíncrono
Considere um código semelhante, mas suponha que cada iteração ocorra como uma
reação a um toque em um botão. Conforme o usuário toca repetidamente no botão, o
aplicativo imprime o próximo elemento em uma matriz:
var matriz = [1, 2, 3]
para número na matriz {
imprimir(número)
matriz = [ 4 , 5 ,
}}
imprima (matriz)
var matriz = [1, 2, 3]
var índice atual = 0
// Este método está conectado no Interface Builder a um botão
@IBAction func printNext(_sender: Any) {
print (array [ currentIndex ] )
if currentIndex != array .count - 1 { ;
índice atual += 1
}}
}}
Pense neste código no mesmo contexto que você fez para o anterior. À medida que o
usuário toca no botão, isso imprimirá todos os elementos do array? Você realmente
não pode dizer. Outro pedaço de código assíncrono pode remover o último elemento,
antes de ser impresso.
27. raywenderlich. com

RxSwift - Programação reativa com Swift Capítulo 1: Olá, RxSwift! Ou outro pedaço de
código pode inserir um novo elemento no início da coleção após
você seguiu em frente.
Além disso, você assume que apenas printNext(_:) mudará currentIndex, mas outro
pedaço de código pode modificar currentIndex também – talvez algum código
inteligente que você adicionou em algum momento após criar a função acima.
Você provavelmente já percebeu que alguns dos principais problemas com a escrita de
código assíncrono são: a) a ordem em que as partes do trabalho são executadas e b)
dados mutáveis compartilhados.
Felizmente, estes são alguns dos pontos fortes do RxSwift!
Em seguida, você precisa de uma boa cartilha na linguagem que o ajudará a começar a
entender como o RxSwift funciona e quais problemas ele resolve; isso permitirá que
você ultrapasse essa introdução suave e escreva seu primeiro código Rx no próximo
capítulo.
Glossário de programação assíncrona
Parte da linguagem no RxSwift está tão fortemente ligada à programação assíncrona,
reativa e/ou funcional que será mais fácil se você primeiro entender os seguintes
termos fundamentais.
Em geral, o RxSwift tenta resolver os seguintes problemas:
1. Estado e, especificamente, estado mutável compartilhado
Estado é um pouco difícil de definir. Para entender o estado, c

5. Sistemas reativos
Sistemas reativos é um termo bastante abstrato e abrange aplicativos da Web ou iOS
que exibem a maioria ou todas as seguintes qualidades:
• Responsivo: sempre mantenha a interface do usuário atualizada, representando o
estado mais recente do aplicativo.
• Resiliente: cada comportamento é definido isoladamente e fornece erros flexíveis
recuperação.
• Elastic: O código lida com cargas de trabalho variadas, muitas vezes implementando
recursos como coletas de dados lentas orientadas por pull, limitação de eventos e
compartilhamento de recursos.
• Orientado a mensagens: os componentes usam comunicação baseada em
mensagens para melhorar a reutilização e o isolamento, desvinculando o ciclo de vida
e a implementação de classes.
Agora que você tem uma boa compreensão dos problemas que o RxSwift ajuda a
resolver e como ele aborda esses problemas, é hora de falar sobre os blocos de
construção do Rx e como eles funcionam juntos.
Fundação do RxSwift
A programação reativa não é um conceito novo; já existe há bastante tempo, mas seus
conceitos principais fizeram um retorno notável na última década.
Nesse período, os aplicativos da Web se envolveram mais e estão enfrentando o
problema de gerenciar UIs assíncronas complexas. No lado do servidor, os sistemas
reativos (como descrito acima) tornaram-se uma necessidade.
Uma equipe da Microsoft assumiu o desafio de resolver os problemas de
desenvolvimento de aplicativos assíncronos, escaláveis e em tempo real que
discutimos neste capítulo. Eles trabalharam em uma biblioteca, independentemente
das equipes principais da empresa, e por volta de 2009, ofereceram uma nova
estrutura de cliente e servidor chamada Reactive Extensions
para .NET (Rx).
Era um complemento instalável para .NET 3.5 e, mais tarde, tornou-se uma biblioteca
central integrada
em .NET 4.0. É um componente de código aberto desde 2012. O código aberto
permitiu que outras linguagens e plataformas reimplementassem a mesma
funcionalidade, o que transformou o Rx em um padrão multiplataforma.
31. raywenderlich. com
RxSwift - Programação reativa com Swift Capítulo 1: Olá, RxSwift!
Hoje você tem RxJS, RxKotlin, Rx.NET, RxScala, RxSwift e muito mais. Todas essas
bibliotecas se esforçam para implementar o mesmo comportamento e as mesmas APIs
expressivas, com base no padrão Reactive Extensions. Por fim, um desenvolvedor que
cria um aplicativo iOS com RxSwift pode discutir livremente a lógica do aplicativo com
outro programador usando RxJS na web.
Como o Rx original, o RxSwift também funciona com todos os conceitos que você
cobriu até agora: ele aborda o estado mutável, permite compor sequências de eventos
e melhora os conceitos de arquitetura, como isolamento de código, reutilização e
dissociações.
Vamos rever essa definição:
Você pode ler mais sobre a família de implementações Rx em http://reactivex.io. Este
é o repositório central de documentação sobre os operadores e classes principais do
Rx. Provavelmente também é o primeiro lugar em que você notará o logotipo Rx, a
enguia elétrica (uma imagem um pouco mais realista que você encontrará na capa
deste livro):
Neste livro, você abordará os conceitos fundamentais do desenvolvimento com o
RxSwift, bem como exemplos do mundo real de como usá-los em seus aplicativos.
Os três blocos de construção do código Rx são observáveis, operadores e agendadores.
As seções abaixo cobrem cada um deles em detalhes.
O RxSwift encontra o ponto ideal entre o código Cocoa tradicionalmente imperativo e
o código funcional purista. Ele permite que você reaja a eventos usando definições de
código imutáveis para processar partes assíncronas de entrada de maneira
determinística e combinável.
Nota: Eu pessoalmente pensei por um tempo que era um camarão tecno, mas
pesquisas mostram que é, de fato, uma enguia elétrica. (O projeto Rx costumava ser
chamado de Volta.)
32. raywenderlich. com

RxSwift - Programação reativa com Swift Capítulo 1: Olá, RxSwift! Observáveis

A classe Observable<T> fornece a base do código Rx: a capacidade de produzir de
forma assíncrona uma sequência de eventos que pode “carregar” um instantâneo
imutável de dados genéricos do tipo T. Em palavras mais simples, permite que outros
objetos ou consumidores assinem para eventos, ou valores, emitidos por outro objeto
ao longo do tempo.
A classe Observable<T> permite que um ou mais observadores reajam a qualquer
evento em tempo real e atualizem a interface do usuário do aplicativo ou processem e
utilizem dados novos e recebidos.
O protocolo ObservableType (ao qual Observable<T> está em conformidade) é
extremamente simples. Um Observável pode emitir (e observadores podem receber)
apenas três tipos de eventos:
• Um próximo evento: Um evento que “carrega” o valor de dados mais recente (ou
“próximo”). É assim que os observadores “recebem” valores. Um Observável pode
emitir uma quantidade indefinida desses valores, até que um evento de término seja
emitido.
• Um evento concluído: Este evento encerra com sucesso a sequência de eventos. Isso
significa que o Observável completou seu ciclo de vida com sucesso e não emitirá
nenhum evento adicional.
• Um evento de erro: O Observable termina com um erro e não emitirá eventos
adicionais.
Ao falar sobre eventos assíncronos emitidos ao longo do tempo, você pode visualizar
uma sequência observável de inteiros em uma linha do tempo, assim:
Este simples contrato de três eventos possíveis um Observ