Use a concorrência estruturada com o framework Network

Oi! Meu nome é Scott. Estou muito feliz em compartilhar algumas melhorias que deixam seu código de rede ainda mais divertido e fácil de escrever. Se você nunca escreveu uma linha de código de rede, você está no lugar certo. E se já escreveu, tenho umas APIs interessantes para mostrar a você. Vou começar mostrando como criar conexões. Depois vou me aprofundar no uso dessas conexões para enviar e receber dados.

Em seguida, discutirei como escutar conexões de entrada. E, por fim, mostrarei como encontrar e se conectar a outros dispositivos na rede. Vamos começar fazendo conexões. O framework Network permite que você faça conexões seguras, combináveis e modernas no app. Foi-se o tempo dos soquetes, estruturas sockaddr, comandos ioctl difíceis de lembrar e operações bloqueadoras. O framework Network conta com o Connect by Name, que fará o trabalho de resolver nomes para você. Resolvido o nome, ele apresenta algo chamado Happy Eyeballs, que garante a escolha eficiente do melhor endereço resolvido para conectar você dinamicamente.

A segurança via TLS é integrada, então você não precisa adicionar outra biblioteca, geralmente com uma API totalmente diferente, ao app apenas para proteger a privacidade dos usuários. Ele também permite transições de interface de rede e proxies, aceitando recursos como Wi-Fi Assist e protocolos de multicaminho, sem que você precise fazer absolutamente nada.

Transportes modernos, como o QUIC, são permitidos, assim como a combinação de seus próprios protocolos com os integrados para que você foque na lógica de negócios e na experiência do usuário, e não perca tempo depurando por que as mensagens não chegam do ponto A ao ponto B. Para aqueles que lidam com apps nativos e apps online, o framework Network também dá suporte robusto a web sockets, permitindo que um único servidor atenda toda a gama de apps do cliente.

O framework Network foi criado com a intenção de ser combinável. Isso significa que, ao utilizar o framework Network, você será recompensado com um conjunto familiar de APIs (mesmo que os protocolos evoluam com o tempo), melhorando o desempenho e a privacidade. Se você já escreveu código de rede usando TCP com a API de soquete BSD, saberá que mudar para algo como o QUIC implicaria em uma reescrita significativa. Com o framework Network, a mudança para o QUIC poderia ser realizada durante um almoço executivo. No iOS e macOS 26, o framework Network se integra perfeitamente ao suporte robusto do Swift para operações assíncronas e concorrência estruturada. Agora, o código de rede se encaixará perfeitamente ao restante do código Swift, facilitando a criação e a manutenção dos apps. Para quem é novato em redes, vou apresentar alguns conceitos neste exemplo que podem parecer desconhecidos, mas não se preocupe, tudo fará sentido no final.

Digamos que você esteja escrevendo seu app e queira se comunicar com um servidor em www.example.com na porta 1029. Você deseja usar o TLS e só deseja fazer essa conexão em uma rede sem restrições. Seu endpoint é o destino da conexão. Sua pilha de protocolos é como você deseja se conectar. Seus parâmetros ajudam a refinar como você chega lá.

Você combina tudo para criar um NetworkConnection. Vamos ver um exemplo de como isso funciona na prática.

Faço uma conexão inicializando meu NetworkConnection com o endpoint e a pilha de protocolos desejada. Neste exemplo, especifico que minha pilha de protocolos é TLS. Note que TCP e IP são inferidos para mim. Só tenho que especificá-los se quiser personalizar algo, mas os padrões funcionam bem quase sempre.

Quando quero modificar os padrões, ainda faço isso de modo declarativo. Vou desativar a fragmentação de IP para esta conexão como exemplo.

Primeiro, preciso especificar os protocolos TCP e IP abaixo do TLS. E então, posso personalizar as opções definidas para IP de modo a desativar a fragmentação.

Se alguém ativa o modo de economia de dados para minimizar o uso da rede, modifico o comportamento da minha conexão para que ela proíba o uso dessas interfaces de rede restritas.

Atualizo o código para que eu possa modificar os parâmetros da conexão porque não vou mais usar os parâmetros padrão que foram criados para mim automaticamente.

A pilha de protocolos permanece a mesma, mas adiciono parâmetros personalizados para que, nessa conexão, o framework Network considere apenas interfaces de rede que não estejam no modo de economia de dados. Legal! Com o mesmo estilo declarativo que tornou o SwiftUI tão popular, meu código de rede transmite uma sensação semelhante ao meu código de interface. Seria ótimo se a rede estivesse sempre disponível, mas as condições da rede mudam o tempo todo. Ao contrário dos soquetes, o NetworkConnection responderá a essas alterações de estado para você.

Quando a conexão for iniciada, ela entrará no estado de preparação enquanto os handshakes do protocolo são realizados. Quando esse processo for concluído, a conexão estará estabelecida. Se não houver conectividade, a conexão sairá do estado de preparação e entrará no estado de espera.

Quando o framework Network detectar que as condições de rede foram alteradas, ele voltará para a preparação enquanto tenta se conectar ao endpoint remoto. Quando a conexão estiver estabelecida, os dados poderão ser enviados e recebidos.

Quando a conexão estiver estabelecida, se houver um erro ou se a conectividade for perdida, ela passará para o estado de falha com uma mensagem de erro para informar o ocorrido.

Encerrar ou cancelar a tarefa associada à conexão fará com que ela entre no estado cancelado. A melhor parte disso é que você não precisa estar ciente desses estados de conexão, se não quiser. Você pode chamar as funções send e receive, e o NetworkConnection aguardará até que essas operações possam ser concluídas. Mas, caso queira saber o estado da conexão, para atualizar a interface, você pode instalar um manipulador que será chamado quando a conexão mudar de estado. Agora você já sabe como fazer uma conexão. Então, vamos começar a usá-la para enviar e receber dados na rede.

Send e receive são funções assíncronas, e ambas iniciarão a conexão, se ela ainda não tiver sido iniciada.

Send usa um objeto de dados e suspende a tarefa até que o framework Network tenha processado os dados.

TLS e TCP são protocolos de fluxo, portanto, ao receber dados, você precisa especificar quantos bytes deseja. Neste exemplo, estou especificando exatamente o número de bytes que desejo ler. Receive retorna uma tupla de conteúdo e metadados, mas neste exemplo, especifico que quero apenas o conteúdo.

Ambas as funções lançarão erros se a conexão encontrar um erro. Por exemplo, se a rede for perdida porque o Modo Avião foi ativado, você poderá usar o erro associado para explicar por que a transferência foi interrompida. Às vezes, você não sabe quantos bytes de dados receber. Neste exemplo, estou carregando uma imagem da rede. Um número inteiro de 32 bits que recebo na minha conexão me diz quantos bytes restantes de dados de imagem há para receber. Usando esse valor, chamo receive repetidamente até que a imagem esteja completa.

No último exemplo, usei a versão de receive que especifica um número exato de bytes. Neste exemplo, uso a versão de receive que me permite especificar um número mínimo e máximo de bytes a serem recebidos. Fazer desse forma permite que o código analise a imagem à medida que os bytes chegam da rede, sem precisar esperar a imagem completa. Protocolos de fluxo de bytes, como TLS, são ótimos, mas talvez você queira estruturar os bytes que está enviando e recebendo, para que possa trabalhar com mensagens em vez de bytes. No exemplo em que descobri o tamanho da imagem lendo um valor de 32 bits do fluxo de bytes antes do conteúdo da imagem, foi uma forma de enquadrar a imagem com o comprimento para separá-la das imagens vizinhas. Tive que fazer isso porque os protocolos de streaming não preservam os limites das mensagens. Isso significa que o número de bytes enviados em uma operação de envio não será necessariamente o mesmo número de bytes recebidos na operação de recebimento do outro lado da conexão. Por exemplo, se você chamar send com três blocos de dados, o outro lado poderá recebê-los um byte por vez, todos de uma vez, ou de alguma forma intermediária. Isso pode complicar significativamente a criação de apps robustos em rede. Felizmente, o framework Network pode ajudar. A novidade no iOS e macOS 26 é o tempo, duração e valor, ou TLV frame integrado, que estrutura as mensagens para que aquilo que você envia de um lado da conexão seja exatamente o que é recebido do outro lado. O TLV é um protocolo de mensagem simples que codifica um tipo, que pode ser usado para descrever os dados contidos na mensagem, e uma duração, que é o tamanho dos dados na mensagem. Em seguida, vem o conteúdo da mensagem. Os protocolos de rede comuns usam TLV, portanto, esse pode ser um formato que seu servidor já conheça. Vamos testar. Neste exemplo, vou enviar e receber tipos de mensagem de jogo. GameMessage é um enum, que usarei como o tipo da mensagem. O conteúdo da mensagem será um personagem do jogo ou um movimento do jogo. Adicionar TLV é tão simples quanto adicioná-lo à minha pilha de protocolos. Como o TLV vai estruturar as minhas mensagens, a interface para envio e recebimento é um pouco diferente.

Vou codificar minha struct GameCharacter usando o JSONEncoder e enviá-la. Observe que estou especificando o tipo da mensagem com os dados codificados. Agora vamos ver como eu recebo mensagens usando TLV.

Ao contrário do exemplo anterior com protocolos de fluxo de bytes, quando uso TLV, não preciso especificar o número de bytes a serem recebidos, pois o TLV analisará a mensagem para mim. Como quero saber o tipo da mensagem recebida, recebi a tupla do conteúdo e os metadados associados à mensagem. No caso do TLV, os metadados incluem o tipo. Eu uso o tipo para determinar que tipo de conteúdo recebi e, com essa informação, decodifico os dados e imprimo o que recebi. Isso é realmente poderoso, especialmente ao interoperar com servidores e protocolos existentes que não controlo. Agora consegui estruturar meus bytes sem muita dificuldade e já consigo enviar e receber mensagens. Essa é uma boa melhoria em relação ao uso direto de protocolos de fluxo de bytes.

Mas e se eu pudesse simplesmente enviar meus objetos diretamente? A novidade no iOS e no macOS 26 é o suporte para envio e recebimento direto de tipos codable, o que pode ajudar a simplificar parte desse código padronizado.

Posso compactar o caractere e mover as structs para dentro do próprio enum GameMessage. O Coder é um protocolo que posso adicionar à minha pilha de protocolos para estruturar mensagens e permitir o envio e recebimento de tipos codable, sem precisar serializá-los e desserializá-los manualmente. Neste código, estou enviando mensagens de jogo de um lado para o outro. Vou inicializar o coder com o tipo que estou enviando e recebendo, e com a forma como quero que o Coder formate os dados. O framework Network tem suporte interno para os formatos JSON e lista de propriedades. Vou escolher JSON para este exemplo. Agora, posso enviar mensagens de jogo sem fazer nenhuma codificação.

Chamar receive na minha conexão retornará uma mensagem de jogo, sem precisar fazer nenhuma decodificação intermediária para converter de um objeto de dados para um objeto GameMessage. Agora, posso enviar e receber mensagens de jogo sem fazer nenhum trabalho extra. Posso me concentrar na lógica de negócios e na interface de usuário do meu app sem sobrecarregar tudo com um monte de código de rede personalizado.

Agora você já sabe como criar uma conexão com um endpoint e enviar e receber dados usando essa conexão. Você aprendeu sobre protocolos de fluxo de bytes, como TCP e TLS, e como adicionar protocolos de estruturação à sua pilha para trabalhar com mensagens, e não com fluxos de bytes. Mas e quanto aos apps que escutam conexões de entrada?

As conexões de entrada são tratadas pelo NetworkListener. Assim como o NetworkConnection, eu o inicializo declarando uma pilha de protocolos. Ao contrário de uma conexão, um ouvinte não tem um método de envio ou recebimento.

Isso ocorre porque um ouvinte escuta novas conexões e as repassa para o chamador. O NetworkListener tem um método run que repassa as novas conexões ao manipulador que foi fornecido. Vamos ver como isso funciona. Eu crio meu NetworkListener de modo declarativo especificando uma pilha de protocolos. Neste exemplo, minhas conexões de entrada poderão enviar e receber objetos GameMessage criptografados por TLS.

Chamar run no NetworkListener iniciará a entrega de novas conexões de entrada ao manipulador que passei para run.

O NetworkListener iniciará uma nova subtarefa para mim a cada nova conexão. Assim, posso executar operações assíncronas no meu fechamento sem me preocupar em impedir que o ouvinte continue entregando novas conexões de entrada. Quando recebo uma nova conexão, uso a propriedade messages em NetworkConnection para tratar as mensagens recebidas do cliente. Então, agora, criei um NetworkConnection para um endpoint que eu já tinha e codifiquei escutando novas conexões. Mas agora quero criar um NetworkConnection cujo endpoint eu não conheço antecipadamente. O NetworkBrowser me permite descobrir endpoints que posso usar ao criar minhas conexões. A novidade do iOS 26 é o Wi-Fi Aware, uma tecnologia de rede ponto a ponto multiplataforma que permitirá a descoberta e a conexão com uma ampla gama de dispositivos compatíveis. Você pode usar o framework DeviceDiscoveryUI para localizar e emparelhar com dispositivos próximos usando o Wi-Fi Aware. Se preferir, você pode procurar serviços anunciados pelo Bonjour. Para saber mais sobre o Wi-Fi Aware, assista ao vídeo "Melhorar a conectividade do dispositivo com o Wi-Fi Aware". Quando quiser encontrar dispositivos em sua rede, seja perto com o Wi-Fi Aware ou via Bonjour, use o NetworkBrowser. O NetworkBrowser usa descritores de busca, que descrevem o que você está tentando encontrar. Como o NetworkConnection, ele também usa parâmetros, que descrevem como você deseja encontrá-lo. Mas, ao contrário do NetworkConnection e NetworkListener, o NetworkBrowser não aceita uma pilha de protocolos. Isso porque o único trabalho do NetworkBrowser é retornar endpoints que possam ser usados para fazer conexões.

Neste exemplo, crio meu NetworkBrowser para procurar dispositivos próximos usando o serviço Wi-Fi Aware, Tic-Tac-Toe. Chamar o método run no navegador fará com que ele seja iniciado e forneça conjuntos de endpoints ao manipulador. No meu app, não tenho preferência por endpoint, então, escolho o primeiro endpoint que é retornado do navegador. Retornar .finish com o endpoint fará com que o navegador pare de funcionar e o endpoint seja retornado da função run. Posso então usar esse endpoint para inicializar um NetworkConnection exatamente da mesma maneira que usei um endpoint para inicializar um NetworkConnection nos exemplos anteriores. O mais interessante sobre esse endpoint, no entanto, é que o navegador o descobriu para mim, eu não precisei conhecê-lo com antecedência.

Com todos esses novos protocolos, você pode se perguntar qual deles escolher para usar no seu app. Essa é uma ótima pergunta. A resposta não é tão complicada quanto você imagina. Se você estiver comunicando com um servidor ou outro dispositivo que não controla, o protocolo já foi escolhido para você. Por exemplo, você está se comunicando com uma impressora via IPP por TCP. Se estiver se comunicando com seu próprio app em outro dispositivo, não tem erro ao usar o Coder por TLS ou QUIC.

Observe que, se você estiver fazendo comunicação HTTP e já estiver usando URLSession, não será preciso fazer nada no seu código. E se você estiver usando a API C do framework Network ou estiver trabalhando em Swift e preferir usar manipuladores de conclusão, também não será preciso alterar nada no código. Você ainda terá suporte para conexão por nome, composibilidade, mobilidade e segurança integrada sempre que usar URLSession ou o framework Network, em qualquer uma de suas formas.

Vamos fazer uma rápida recapitulação. As novidades no iOS e no macOS 26 são NetworkConnection, NetworkListener e NetworkBrowser. Você aprendeu a usar um NetworkConnection com estruturação TLV e suporte para enviar e receber tipos codable com o protocolo Coder. O NetworkListener pode ser usado para escutar conexões de entrada. E o NetworkBrowser pode ser usado para procurar endpoints na rede. Tudo isso facilita como nunca o desenvolvimento de apps em rede. Então é isso. Essas novas APIs foram criadas do zero para a concorrência estruturada do Swift. Elas são criadas de modo declarativo, assim como a construção de uma interface no SwiftUI. Elas são executadas em tarefas e serão canceladas automaticamente quando a tarefa em questão for cancelada. Experimente as novas APIs para aproveitar ao máximo a concorrência estruturada no Swift, deixando seu código mais limpo e eliminado toneladas de repetições. Tudo isso com o mesmo poder e flexibilidade que o framework Network oferece para uso em seus apps. Agradeço sua participação.