(Música techno animada)
Olá, pessoal. Meu nome é Ryan.
Sou engenheiro de software na equipe do Firebase
e trabalho em SDKs da Apple no escritório de Waterloo, Canadá.
E eu sou Chen.
Sou engenheira de software na equipe do Firebase
e também trabalho em SDKs da Apple. Estou no escritório de Sunnyvale, Califórnia.
O Firebase visa ajudar pessoas desenvolvedoras a ter sucesso
ao facilitar a criação e operação de aplicativos.
Sabemos que o Firebase é um kit para diferentes plataformas,
com suporte para iOS, Android, Web, CIMA + e Unity.
Mas nós sabemos por que você está aqui.
Você já deve saber que o ecossistema da Apple
facilitou o desenvolvimento de aplicativos multiplataforma
não só para iOS e iPadOS, mas para macOS, WatchOS, tvOS e Catalyst.
Uau, que lista longa.
No Firebase, estamos examinando alguns casos de uso
e disponibilizando-os nas plataformas da Apple.
Os SDKs do Firebase para plataformas Apple oferecem flexibilidade para desbloquear
fluxos de desenvolvimento para iOS,
e eles continuarão a fazer mais no futuro.
Criar e executar aplicativos para iOS e outras plataformas da Apple
mudou nos últimos anos.
O Swift se tornou a linguagem prática para a criação de aplicativos.
Abordaremos alguns recursos e estruturas da linguagem Swift nesta sessão.
O SwiftUI, por exemplo, nos permite construir belas interfaces
usando uma sintaxe simples e concisa.
O Swift Package Manager está mais fácil para incluir SDKs do Firebase no seu projeto.
Async-await e Combine
são novas maneiras de pensar a programação assíncrona.
No Firebase, observamos essas mudanças de perto
e hoje mostraremos nossa abordagem para as mudanças no ecossistema.
Mas primeiro, Chen, como está o repositório do GitHub?
Vou te contar, Ryan,
desde que o Firebase começou a abrir o código-fonte dd nossas bibliotecas em 2017,
a maioria dos SDKs do Firebase para plataformas Apple
está disponível hoje no GitHub.
Abrimos o código-fonte do SDK de desempenho do Firebase
no final de 2020. Caso ainda não tenha visto,
vá dar uma olhada e nos diga o que você acha.
Continuamos com nosso compromisso de maior transparência
e de construir uma comunidade forte de desenvolvedores.
Já fechamos mais de 2 mil problemas e fizemos merge de mais de 5 mil pull requests.
Nossa equipe do Firebase adora interagir com vocês no GitHub.
Encorajamos que deem seu feedback,
não importam as solicitações de recursos ou bugs,
porque vocês podem falar direto com os engenheiros
que se baseiam nos SDKs, incluindo Ryan e eu.
Isso também facilita as conversas técnicas.
Temos a sorte de ter uma comunidade incrível de colaboradores.
Atualmente vocês são 139
contribuindo no SDK do Firebase para plataformas Apple.
Estamos vendo colaborações ativas de código aberto
entre membros da comunidade e Firebasers
trabalhando juntos no suporte.
Queremos agradecer a todo mundo por tornarem nossos SDKs melhores.
Ser de código aberto tornou muitas coisas possíveis.
Ser capaz de percorrer o código e saber como seu SDK se comporta
economiza horas de busca por bugs.
Isso também habilitou recursos como suporte da comunidade
para tvOS, macOS, Catalyst e WatchOS.
Adicionamos o suporte a WatchOS da comunidade
para banco de dados e configuração remota.
Experimente isso no seu app para smartwatch
e use as discussões do GitHub para fazer perguntas.
Muitos de vocês já começaram a usar o Swift Package Manager
para gerenciar dependências.
Hoje, o Firebase é oficialmente compatível com o Swift Package Manager.
Assim, além do CocoaPods, agora pode-se usar o Swift Package Manager
para adicionar o Firebase ao aplicativo.
Vou mostrar rapidamente como fazer porque é muito fácil.
Primeiro, obtenha os URLs da página de relatório do SDK do Firebase para iOS.
Copie e cole os URLs da página.
Isso funciona na maioria das bibliotecas hospedadas ou distribuídas pelo GitHub.
Agora, abra o aplicativo no seu código X, clique na guia Arquivo
e selecione o pacote Swift. Em seguida, clique em Adicionar Dependência de Pacote,
cole os URLs e clique em Avançar.
Selecione a versão ou ramificação desejada.
Recomendamos obter a versão mais recente de nossos SDKs
não só pelos novos recursos,
mas também por correções de bugs ou melhorias.
Logo depois, você pode selecionar o produto que deseja usar.
Aqui, usaremos o Analytics Auth,
e queremos experimentar as novas APIs do SwiftUI.
Uma coisa a saber: se você quiser adicioná-lo a um destino diferente,
por exemplo, um alvo independente,
e você só deseja instalar o messaging no app para smartwatch,
você pode escolher um alvo no lado direito.
Quando terminar, clique e conclua, então você poderá ver os pacotes
se clicar em Projeto e selecionar Pacotes Swift.
Se quiser adicionar mais SDKs do Firebase depois,
você pode ir ao alvo que deseja editar, clicar em Geral,
e em Frameworks, Bibliotecas e Conteúdo Integrado.
Você pode adicionar SDKs do Firebase ou excluir alguns de que não precisa mais.
Agora que criamos um novo projeto com o Swift Package Manager,
vamos ouvir o Ryan falar mais sobre Swift e SwiftUI.
Obrigado, Chen.
Apesar de nossos SDKs serem escritos principalmente em Objective C,
avaliamos cada API para ver como ela é importada para o Swift
e tentamos tornar a experiência ótima.
E quanto às coisas como tipos de resultados, suporte a Codable,
parâmetros padrão ou enums e tipos associados?
Podemos aproveitar esses ótimos recursos do Swift
ao usar Objective C. Às vezes, só precisamos escrever código em Swift.
Por isso, começamos a lançar extensões de Swift opcionais para diferentes SDKs.
E algumas foram contribuições da comunidade.
Vamos examinar alguns destaques. Veremos bastante código.
Neste trecho estamos baixando uma imagem do armazenamento do Firebase
usando o bloco de manipulador de conclusão.
Dados e erros são opcionais
e isso leva a um código estranho que nos faz forçar unwrap no erro
É algo que queremos evitar.
O erro deve estar preenchido quando os dados são vazios,
e os dados sempre devem ser vazios quando há um erro.
Mas não podemos impor isso no compilador com o código existente.
Ao alternar para a função fornecida pela nova extensão do Swift,
podemos eliminar esse estado e o force unwrap.
Com uma instrução switch, obtemos a segurança do compilador
de ter apenas dois estados representados. Temos dados ou temos um erro.
Sem estados intermediários. Vamos falar do Firestore e análise de dados.
Este é um trecho de código que mostra a análise de dados de uma versão anterior
da nossa introdução ao Firestore. Após obter os dados do Firestore,
queremos convertê-los em um tipo local do dicionário fornecido,
neste caso, um restaurante. Esse tipo de código lhe parece familiar?
Fico triste sempre que leio o menu com unwrap de um erro em chaves de string,
sem aproveitar os recursos de segurança de tipos do Swift.
É frágil, difícil de ler e fácil de cometer erros ao escrevê-lo.
Vamos adicionar uma conformidade Codable ao nosso tipo restaurante.
Ao confirmar o protocolo Codable,
a análise manual de código é feita sem o seu esforço,
pois é gerada pelo compilador, e atualizações continuam consistentes em todo o tipo.
Ler esses dados do Firestore
agora é tão fácil quanto chamar os dados como uma função
em DocumentSnapshot e analisar no tipo restaurante.
Chega de analisar manualmente esse objeto. Codable faz todo o trabalho.
Configurar os dados no Firestore também é fácil,
passando a instância diretamente em vez de uma representação de dicionário dela.
Acabamos de publicar uma API parecida para banco de dados do Firebase,
graças a um colaborador externo.
Agora, o novo e empolgante SwiftUI. Este é o meu favorito.
Recentemente lançamos APIs específicas do SwiftUI com mais pela frente.
A WWDC 2020 apresentou um novo ciclo de vida de aplicativos do SwiftUI
que é compartilhado entre plataformas.
Anteriormente, recomendamos que você insira FirebaseApp.configure
na parte superior do seu aplicativo que finalizou a chamada em AppDelegate
Bem, onde ele deve ficar se não houver uma classe AppDelegate?
Basta sobrepor a função init que é chamada quando um aplicativo é iniciado
e chamar FirebaseApp.configure.
Isso permanece verdadeiro mesmo que você use um aplicativo de IU delegado
para tratar coisas como notificações push,
que veremos depois, em uma demonstração da Chen.
A primeira API nova que mostrarei registra eventos manuais de visualização de tela
no Google Analytics para Firebase. Essa API existente
registra visualizações de tela e classes de tela para o kit de IU,
mas devido ao fato do SwiftUI
não ter um controlador de visualização de IU correspondente que possamos acessar,
isso não funciona ao usar o SwiftUI.
Felizmente, adicionamos um evento de visualização de tela manual
para você ter um controle cuidadoso sobre o momento de registro dos eventos.
Isso se encaixa ao escrever o kit de IU, Integrando isso em viewDidAppear,
ele costuma ficar fora do caminho.
Vejamos como isso fica no SwiftUI.
Chamamos as APIs de registro manuais
sempre que uma visualização aparece usando o modificador onAppear.
Isso funciona, mas é muito prolixo e pode bagunçar o código
e tirar a estrutura da visualização.
Este é o limite do que podemos oferecer do ponto de vista da API em Objective C,
mas no Swift isso é melhor.
É uma ótima chance para um modificador de visualização personalizado,
e é exatamente isso que construímos.
Agora marca-se uma visualização
com o modificador de visualização de tela analítico fornecido
para declarar o nome da visualização, a classe ou a estrutura,
mas estamos combinando a nomenclatura analítica existente
e quaisquer parâmetros extras que se queira registrar
quando esta visualização aparece na tela.
Graças aos argumentos padrão do Swift, você pode fornecer apenas o nome
e o resto é opcional. Como neste caso,
deixamos de fora o argumento de parâmetros extras.
Estamos entusiasmados com esta nova forma
de marcar visualizações e registrar eventos de visualização.
Outra melhoria que lançamos é construir visualizações próprias de mensagens no app.
Neste exemplo, usamos o modificador modalInAppMessage.
O fechamento é um construtor
e os argumentos são a mensagem que contém os dados
que foram configurados no console,
mais o delegado para notificar o SDK de mensagens no aplicativo
sobre interações, como quando uma mensagem é aberta ou dispensada
para registrar métricas e impressões.
Há APIs que cobrem cada tipo de mensagem e facilitam muito o fornecimento
de interfaces personalizadas das suas mensagens no app.
Conte-nos na discussão do GitHub se tiver ideias
de outras dicas do SwiftUI que queira ver.
A comunidade está animada com o Combined e não podemos culpá-la.
Nós também estamos. Recebemos contribuições incríveis
de pessoas da comunidade
e temos trabalhado em algumas mudanças.
Ainda há trabalho a ser feito na área,
mas aqui está uma prévia do que você pode esperar.
Escrevemos este publisher para o login do Auth usando um e-mail e senha.
Ele retorna um future combinado
do resultado dos dados do Auth ou do erro associado.
Isso está um pouco simplificado, mas neste pipeline
estamos extraindo o usuário, substituindo todos os erros por nil
e o atribuindo à propriedade de usuário conectado
que é representada na IU.
Temos vários publishers em diferentes SDKs
para ajudar no fluxo de dados do Async.
Fique de olho no progresso das nossas APIs combinadas
usando o projeto no nosso GitHub. O Combine não é o único progresso animador
feito na manipulação assíncrona de código. Estamos perto de ver Async/await
em um lançamento da cadeia de ferramentas de Swift.
Vamos ver de novo o login com e-mail e senha,
comparando o manipulador de conclusão com Async/await.
Usamos manipuladores de conclusão para lidar com o fluxo de controle.
Dentro do manipulador, podemos querer fazer mais chamadas assíncronas
que podem levar à clássica pirâmide da destruição.
Como Async/await transforma essa chamada?
Em vez de gerenciar o estado inteiramente no bloco do manipulador de conclusão,
parece mais um código síncrono e é mais fácil de raciocinar.
Podemos continuar fazendo o mesmo em outras chamadas do Async
e será muito mais simples manter o estado
e garantir o tratamento correto de erros.
Agora Chen fará uma demonstração empolgante.
Obrigada, Ryan.
Vamos discutir como você pode fazer o app para smartwatch independente com o Firebase.
Suponha que você queira controlar sua ingestão diária de café.
Algo legal no app para smartwatch independente é poder usá-lo
sem sincronizar com o telefone.
O Firebase visa facilitar a criação do seu app para smartwatch
conectando o smartwatch diretamente ao serviço Firebase Cloud.
Atualmente, temos vários produtos que têm suporte da comunidade para WatchOS
para que você possa, por exemplo, enviar notificações push
do console do Firebase diretamente para o seu aplicativo.
Sincronizar o progresso da ingestão de café com nosso banco de dados
sem um telefone associado.
Ou baixar uma imagem do armazenamento em nuvem direto no smartwatch.
Uma coisa a saber é que os apps configurados no console
devem corresponder individualmente aos apps no Apple Store Connect.
Se o aplicativo cobrir várias plataformas, use um único app do Firebase
e o GoogleService-Info.plist para todas as plataformas que executam o app.
Isso também se aplica a extensões de apps do iOS.
Por exemplo, se um aplicativo tiver um app de iOS e de Mac e o widget de destino,
pode-se importar o GoogleService-Info.plist do app principal para todos os destinos.
Agora que você configurou seu produto Firebase com sucesso
e importou o arquivo plist para o código X, vamos ver como enviar
notificações push diretamente ao app para smartwatch.
Estamos usando o último ciclo de vida do SwiftUI.
Então você notará que não há delegado de extensão disponível.
Isso ocorre porque um ciclo de vida do SwiftUI, por padrão,
não inclui nenhum delegado de extensão ou aplicativo.
O que você pode fazer aqui é usar o adaptador WKExtensionDelegate
para injetar o delegado no app, onde você pode adicionar código
para solicitar permissões de notificação push do WatchOS
e tratar APIs dos SDKs do Firebase que requerem um delegado de aplicativo.
Neste caso, você precisa definir um apnsToken para o SDK messaging.
No passado, essa etapa era tratada automaticamente pelo messaging
quando o swizzling foi ativado.
No entanto, como swizzling se tornou mais frágil,
não recomendamos mais essa abordagem no WatchOS.
Em vez disso, você precisa implementar o método
didRegisterForRemoteNotifications do WKExtensionDelegate
para definir manualmente o apnsToken para o messaging.
O mesmo se aplica ao app iOS se você usar um ciclo de vida do SwiftUI.
Você precisa usar o UIApplicationDelegateAdapter
para injetar seu próprio delegado de aplicativo do kit de IU.
Depois, você pode implementar o código que requer o delegado do app.
Agora mostrarei um trecho de código sobre como baixar uma imagem fofa do Sparky
direto no app para smartwatch. Usamos o armazenamento do Firebase aqui.
Ah, você notou que o mesmo código também pode ser executado no seu app iOS?
O armazenamento do Firebase
não requer uma API de chave especial, como o messaging.
Você pode ter um código quase idêntico para seus apps WatchOS, iOS, tvOS e macOS.
Ainda desbloqueamos um suporte de extensão de app
porque é muito útil, facilitando
para usuários acessarem seu app e fazer outras coisas legais.
Pegue o widget como exemplo.
A extensão widget é uma ótima forma de apresentar informações do seu app
e torná-lo mais atraente para os usuários clicarem.
Este é um trecho de código onde pode-se obter imagens
usando armazenamento na extensão widget.
E assim você tem um Sparky no seu kit de widgets também.
E é uma ótima forma do usuário ver informações importantes do aplicativo
em vez do ícone básico, o que é muito legal.
E é isso.
Esperamos que tenham gostado de criar apps da Apple conosco.
Visitem nosso repositório no GitHub.
Há muitas informações úteis lá.
Experimentem, informem bugs e iniciem discussões do GitHub.
Queremos muito ver o que vocês podem criar com o Firebase.
(Música techno animada)