Seja na área da tecnologia, design, desenvolvimento de produto, gestão ou até mesmo em projetos da universidade, quando falamos de trabalho em equipe a gestão de tempo, qualidade de entregas e evolução contínua do projeto são questões importantes para um bom resultado final. É necessário acompanhar o trabalho dos seu time, combinar prazos e realizar entregas progressivas que agreguem valor ao projeto. Precisamos utilizar estratégias de metodologias ágeis como o Scrum e o Kanban.

De forma objetiva,

Scrum é uma metodologia ágil usada para gerenciar projetos de forma colaborativa, incremental e adaptável e principalmente em cenários de maior incerteza, permitindo uma resposta rápida às mudanças e uma entrega mais flexível. […] Ela preza por utilizar ciclos curtos de trabalho, chamadas de Sprints e que duram entre 1 e 4 semanas. Tem pequenas entregas ao longo do projeto, reuniões curtas diariamente chamadas de Daily, para acompanhar o andamento do projeto. E a cada Sprint, ocorre uma revisão do que foi produzido (incremento no produto) que chamamos de Review e um momento para discutir o que pode ser melhorado (processo) nas próximas Sprints que chamamos de Retrospective.

Veja mais sobre metodologias ágeis no texto de Camila Xavier.

Já o Kanban,

O Kanban é um método visual de gerenciamento de fluxo de trabalho que permite às equipes otimizar e melhorar sempre a entrega de trabalho ao visualizar tarefas, limitar o trabalho em andamento e focar na eficiência do fluxo. Em um sistema Kanban, as equipes visualizam as tarefas em um quadro, movem o trabalho por estágios definidos e usam limites claros para evitar que muito trabalho se acumule de uma vez. Um dos principais princípios do Kanban é tornar os fluxos de trabalho mais fáceis de visualizar, gerenciar e aprimorar.

Veja mais sobre o Kanban nos textos da Atlassian, empresa responsável pela plataforma Jira.

E por que o Jira?

A plataforma unifica a metodologia do Scrum e a visualização dinâmica do Kanban. Mesmo dentro dos planos gratuitos, é possível realizar a organização de um Backlog, lista de tasks para serem entregues, e a divisão dessas por Sprints com tempo de duração determinado pela equipe.

Dentro da página do backlog, o time consegue visualizar em uma única tela as tasks em formato de lista. Em cada uma das tasks é possível escolher um título, alterar o progresso, apontar um prazo de entrega desejado, determinar uma pessoa responsável pela atividade. Além de conseguir facilmente reorganizar o trabalho ao longo do processo.

Para desenvolvimento de software, durante o momento da sprint planning, as sprints devem ser construídas a partir das "user stories". A user story é uma ação completa que o seu usuário precisa realizar: "Como [usuário], quero [ação] para que [objetivo]”, ou seja, ao fim de um sprint o time deve entregar um pedaço de um fluxo para o projeto.

Para auxiliar nas discussões do time, durante o planejamento, de quais tasks devem fazer parte de cada sprint, utiliza-se os story points para estimar o esforço, uma unidade de medida criada a partir da sequência de fibonacci (1, 2, 3, 5, 8, 13). Essa medida tem como objetivo distanciar a discussão de unidades exatas, como horas que podem gerar divergências, e levar à um campo mais abstrato, que pode levar em consideração: dificuldade técnica, tempo de estudo, conhecimento prévio, tempo disponível para o trabalho e a comparação entre tasks, evitando repetir a enumeração em uma mesma sprint.

Em projetos que estão iniciando do zero, escolher bem as atividades e montar user stories realisticamente é muito importante, pois além de aumentar o sentimento de satisfação da equipe ao conseguir visualizar pedaços do seu projeto saindo do papel, proporciona entregas progressivas aos stakeholders, financiadores ou líderes de outras áreas.

Assim como também, facilitar correções e revisões por fluxo de usuário. Sendo mais fácil de realizar alterações e mudanças de rumo durante o processo de construção, ao invés de apenas ao final do projeto, economizando tempo e dinheiro.

Como criar um projeto no Jira pela primeira vez?

1. Acesse o Jira e faça o seu login ou crie um nova conta.
2. Crie um site onde seus múltiplos espaços poderão ser criados
3. De um nome para o seu espaço (você pode criar por equipe, por projeto)
4. Organize o Kanban como preferir

5. Por último, convide seus teammates para o espaço.

E isso resolve tudo?

Não. O Jira não vai eliminar todos os problemas do seu time. Mas, não usá-lo pode gerá-los.

Um projeto sem organização e visualização do processo pode ter dificuldades de identificação de gargalos técnicos, aumento do tempo necessário para entregas efetivas ou ser um gerador de estresse ao time com tarefas complexas que poderiam ter sido melhor administradas, pensadas e que talvez não sejam prioritárias para a entrega final.

Mas, só utilizar a ferramenta, dividindo tarefas e esperando o melhor, sem o uso efetivo do Scrum, das Dailys e do acompanhamento não gerará resultados efetivas, mas sim um quadro com tarefas que ninguém finaliza, testa ou conversa sobre.

Caso deseje aprender mais sobre o Scrum, cheque o último texto de Débora Lemos.

Referências e leituras recomendadas

ATLASSIAN. O que é o Kanban?. Atlassian, 2026. Disponível em: https://www.atlassian.com/br/agile/kanban. Acesso em: 20 out. 2026.

FONSECA, Bruna. O que é uma User Story? Bruna Fonseca, 10 jun. 2021. Disponível em: https://www.brunafonseca.pro.br/post/o-que-é-uma-user-story. Acesso em: 20 out. 2026.

ONES. Story Points vs Original Estimate in Jira: which metric drives better sprint planning? ONES.com Blog, 27 fev. 2026. Disponível em: https://ones.com/blog/story-points-vs-original-estimate-jira-sprint-planning/. Acesso em: 20 out. 2026.

XAVIER, Camila. Metodologias ágeis na área de tecnologia!: importância do gerente de projetos e o uso do Scrum no processo de desenvolvimento de um produto. Medium: Apple Developer Academy | UFPE, 14 maio 2025. Disponível em: https://medium.com/appledeveloperacademy-ufpe/metodologia-ágeis-na-área-de-tecnologia-0dac18d07b4f. Acesso em: 20 out. 2026.

Como usar efetivamente o Jira was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tomar decisões é um aspecto intrínseco a processos criativos. No trabalho em grupo, é importante que esse ato seja realizado de forma organizada, empática e guiada, uma vez que o nível de participação dos integrantes na jornada tem um alto impacto no engajamento, satisfação e sentimento de dono em relação ao que está sendo desenvolvido.

Neste artigo, serão abordados aspectos relevantes de preparação e técnicas para tomada de decisão em grupo. As reflexões sobre o tema surgiram a partir da minha experiência criando e desenvolvendo o aplicativo Pupila, disponível para iOS, com meus colegas da Apple Developer Academy — UFPE. Desse modo, a minha motivação é colaborar para um conhecimento compartilhado e mais amplo sobre maneiras de tornar esses momentos mais fluidos e direcionados.

Metodologia

Em projetos mais longos, é comum o uso de metodologias para guiar o trabalho da equipe. Nesse viés, durante o desenvolvimento do Pupila, utilizamos o Challenge Based Learning (CBL), metodologia que tem como base o aprendizado constante e imersão no universo do problema. De maneira geral, aprende-se enquanto cria uma solução e resolve o problema em questão. O CBL é dividido em três fases principais, interligadas entre si:

• Engage (Engajar): define-se a grande ideia, um tema amplo. Ela fornece propósito e guia o processo. Durante essa etapa, muitos questionamentos são levantados e um desafio mais específico é definido;
• Investigate (Investigar): diante do desafio, são realizadas perguntas/reflexões, as quais são respondidas através de estudo e aprendizado aprofundados. Nesse momento há grande uso do pensamento crítico. Por fim, escolhe-se uma solução e registra-se as sínteses e evidências que baseiam a escolha;
• Act (Agir): desenvolve-se a solução real a partir das decisões anteriores. É importante ser adaptável ao que o público alvo necessita, assim como entender os possíveis erros e acertos durante o caminho para reavaliar o planejamento, se necessário.

Diante do exposto, nota-se que o CBL traz à tona questões interessantes, muito relacionadas à tomada de decisão: flexibilidade e pensamento crítico.

É importante, durante o processo, experimentar o entendimento de outras sugestões e opiniões pela ótica do outro, estando flexível a mudanças de contexto e/ou viés.

Além disso, é essencial pensar criticamente acerca da problemática e das ideias sugeridas, de modo que as decisões sejam fundamentadas, coerentemente, em evidências.

Essas questões, quando praticadas e alinhadas em grupo, criam um ambiente seguro em que as pessoas se sentem confortáveis para compartilhar opiniões, garantindo que o contexto das proposições tenha um fluxo mais natural.

Preparação

Imagine um processo mais complexo de ideação, como a construção de um aplicativo que resolve um problema real. Nele, é necessário identificar a problemática, estudar sobre a área focal, entender o público alvo, dialogar com essas pessoas, realizar pesquisas, entre outras ações. A partir disso, todos os dados coletados, as informações extraídas e as conclusões da equipe devem ser registradas e alinhadas constantemente.

O registro, por sua vez, pode acontecer de diversas maneiras e ter diferentes formatos. No Pupila, utilizamos uma Matriz CSD (Matriz de Certezas, Suposições e Dúvidas) como um "raio X" do grupo, por exemplo. Ela foi atualizada a cada ciclo: algumas suposições viravam certezas, novas dúvidas surgiam… Então ela sempre refletia a visão e posição do grupo no momento, funcionando como um registro “vivo”.

Além da matriz, as construções gerais eram guardadas em outros formatos, tal como documentos escritos, formulários e imagens. Elas eram inseridas em plataformas como o Miro e o Figma, que serviam como nosso acervo de elaborações, decisões, sínteses etc. Quando necessitávamos consultar ou realinhar algum aspecto, partíamos para esses locais.

Outrossim, também é interessante realizar um alinhamento de expectativas da equipe considerando o processo de tomada de decisão. Nesse cenário, além da flexibilidade e do pensamento crítico, outros pilares cruciais são:

• Embasar suas sugestões e justificativas em dados e/ou evidências reais. Para isso, usam-se os registros mencionados previamente neste tópico;
• Ter uma escuta ativa. Ouvindo com atenção e considerando o que está sendo dito por outras pessoas;
• Definir, com clareza, o objetivo final da convergência.

Etapas e técnicas

Entende-se que, para decidir algo, é necessário que existam opções. Desse modo, considerando que a equipe já realizou momentos de geração de ideias previamente, como o Brainstorming, sugiro as seguintes etapas e técnicas, baseadas em estudos e experiências passadas. Contudo, vale ressaltar que não existe uma regra absoluta: tudo depende da dinâmica e necessidades do grupo.

1. Organizar e agrupar

• Juntar todas as ideias em um único local, seja físico ou online;
• Eliminar ideias duplicadas;
• Agrupar ideias semelhantes em categorias, por exemplo, com um Diagrama de Afinidades.

2. Discutir e esclarecer

• Ler as ideias em grupo;
• Abrir espaço para questionamentos rápidos para seus autores.

3. Filtrar e selecionar

• Relembrar qual o objetivo final da decisão;
• Ouvir opiniões organizadamente (por categoria, por ordem de disposição das pessoas no local etc.);
• Selecionar, em grupo, as ideias que fazem mais sentido (Votação por Pontos, Matriz de Impacto x Esforço). Nesse momento, é válido revisitar registros, acordos firmados e decisões anteriores.

4. Refinar e concluir

• Estimular o grupo a construir em cima das ideias selecionadas na etapa 3, combinando-as;
• Definir a ideia final (a partir de uma técnica de seleção, como as citadas previamente);
• Consultar se o time tem alguma objeção (Tomada de Decisão por Consentimento) ou se a ideia fere alguma limitação ou acordo previamente estabelecido;
• Registrar decisão.

Considerações finais

Em suma, guiar um grupo para a convergência de ideias não é um processo rígido.

Embora existam diversas técnicas e metodologias disponíveis para facilitar essa jornada, a escolha ideal sempre dependerá do perfil da equipe com a qual você está trabalhando e do contexto específico do projeto. O que faz mais sentido e funciona perfeitamente para um time pode não ser a melhor abordagem para outro.

Portanto, o mais importante é manter a flexibilidade, a escuta ativa e adaptar essas ferramentas à realidade do seu grupo, garantindo que a tomada de decisão seja um momento colaborativo, engajador e eficaz.

Tomada de decisão: como guiar um grupo para convergir ideias was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Já aplicou o PhotosPicker em algum projeto e tem dúvida de como possibilitar que o usuário selecione vídeos da fototeca e os reproduza em alguma View? A solução está no uso da AVKit.

O que é AVKit?

AVKit é um framework da Apple que fornece as interfaces necessárias para integrar mídia com o hardware e software de um dispositivo, fornecendo o reprodutor de vídeo padrão do sistema. Ele se baseia no AVFoundation, responsável por todo o trabalho de baixo nível por trás da integração de áudio e vídeo. Com o AVKit, o seu projeto pode reproduzir mídia em tela cheia, embutida em linha ou em uma janela flutuante Picture in Picture (PiP).

Abaixo estão os frameworks relevantes:

import SwiftUI
import PhotosUI
import AVKit

Quais são os componentes necessários?

1. PhotosPickerItem — referência retornada pelo PhotosPicker que indica o vídeo selecionado
2. AVPlayer — gerencia a reprodução do vídeo
3. VideoPlayer — visualização que exibe o conteúdo do AVPlayer

Como implementar?

1. Configurar as variáveis necessárias

    var selectedPickerItem: PhotosPickerItem? = nil
    var selectedVideoData: Data? = nil // dados brutos do vídeo
    var isLoading: Bool = false //flag pra indicar se está carregando
    var player: AVPlayer? = nil

2. Criar uma URL temporária

O AVPlayer não reproduz vídeos diretamente a partir de um objeto Data: ele precisa de uma URL. Para contornar esse obstáculo, vamos retornar uma URL temporária, já que, por questões de privacidade, não podemos utilizar a original do PhotosPicker.

    private func criarURLTemporaria(com data: Data) -> URL? {
        let tempDirectory = FileManager.default.temporaryDirectory //acessa a pasta temporária do app (tmp/)
        let tempURL = tempDirectory.appendingPathComponent(UUID().uuidString).appendingPathExtension("mp4") //cria um nome único
        do {
            try data.write(to: tempURL) //grava o vídeo nesse url
            return tempURL //retorna a URL criada
        } catch {
            print("Erro ao criar arquivo temporário de vídeo: \(error.localizedDescription)")
            return nil
        }
    }

3. Processar o vídeo selecionado

Vamos implementar uma função processarVideoSelecionado, com o intuito de transformar o selectedPickerItem em um vídeo reproduzível.

Esta função cria uma Task, a qual roda na thread principal, mas permite que o carregamento aconteça de forma assíncrona (pelo uso do "await"), liberando a interface enquanto o vídeo é carregado e impedindo que o app fique travado.

A Task aguarda o loadTransferable interpretar o vídeo da fototeca como bytes (Data) e os guarda para depois transformá-los em uma URL, a partir da qual será criado o AVPlayer.

    @MainActor
    func processarVideoSelecionado() {
        guard let item = selectedPickerItem else { return } // algum video selecionado?
        
        isLoading = true
        
        Task {
            if let data = try? await item.loadTransferable(type: Data.self) {
                // convertendo o video em bytes para um objeto Data
                self.selectedVideoData = data
                
                if let tempURL = self.criarURLTemporaria(com: data) {
                    self.player = AVPlayer(url: tempURL)
                }
            }
            self.isLoading = false
        }
    }

Observações relevantes:

• o @MainActor garante que ela rodará na thread principal junto à interface. É importante adicionar esse atributo, pois a função irá alterar variáveis que a View observa (isLoading, player).
• o loadTransferable(type: Data.self) não é indicado para arquivos muito grandes.

4. PhotosPicker

Deve-se adicionar um filtro ao PhotosPicker para listar apenas os vídeos do usuário. Depois, deve-se implementar um preview usando AVPlayer

PhotosPicker(
    selection: $selectedPickerItem,
    matching: .videos, //filtra so videos
    photoLibrary: .shared()
) {
    //preview do vídeo usando AVPlayer
    if let player {
        VideoPlayer(player: player)
    }
    else if isLoading {
        ProgressView()
    }
    else {
        Text("Adicionar Vídeo")
    }
}

.onChange(of: selectedPickerItem) {
    processarVideoSelecionado()
} //quando selecionar entra no modo processando
.onDisappear {
    cancelar() //função que limpa a memória ao fechar
}

Tendo feito isso, resta apenas adicionar um botão que salve os dados do vídeo no banco de dados do projeto. No exemplo abaixo, criamos uma nova instância da classe "Video" com os dados do vídeo como atributo (selectedVideoData) e nós a inserimos no ModelContext (classe do SwiftData):

let novoVideo = Video(videoData: selectedVideoData)
context.insert(novoVideo)

5. Prévia do vídeo

Agora, em qualquer tela que você desejar incluir uma prévia desse vídeo que o usuário adicionou ao projeto, basta chamar o componente VideoPlayer em uma View.

if let player {
    VideoPlayer(player: player)
}
else {
    Text("Não há vídeos")
}

Conclusão

Com esses passos base, o seu app já permitirá que o usuário escolha vídeos da biblioteca de fotos, veja uma prévia na hora e guarde o arquivo para assistir depois.

Para além disso, a AVKit também tem muito mais a oferecer (controles personalizados, Picture in Picture, legendas e faixas de áudio, entre outros), então vale a pena explorar a documentação da Apple.

Espero que esse tutorial tenha lhe ajudado a dar os seus primeiros passos com a AVKit! Se tiver quaisquer dúvidas ou sugestões, sinta-se à vontade para deixá-las nos comentários.

Referências

• AVKit | Apple Developer Documentation
• VideoPlayer | Apple Developer Documentation
• AVPlayer | Apple Developer Documentation

Como selecionar e reproduzir vídeos da galeria no SwiftUI com PhotosPicker e AVKit was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

É comum que pessoas iniciantes no desenvolvimento em SwiftUI sustentem a navegação do aplicativo usando somente NavigationStack, normalmente localizadas na ContentView ou outros arquivos raiz, associadas com botões e NavigationLink responsáveis por criar a ligação entre telas. Para projetos de pequeno escopo, com fluxos majoritariamente lineares, esta solução é funcional e resolve o problema. No entanto, quando passamos a lidar com padrões de navegação mais complexos, onde existem várias telas associadas a um único fluxo, precisamos de uma abordagem mais robusta, que permita maior controle da transição entre diferentes View's. Para esclarecer essas limitações, imagine as seguintes situações:

• O usuário precisa ser direcionado para uma tela específica assim que conclui um preenchimento de dados;
• Queremos retornar para uma tela inicial assim que o usuário finaliza um outro fluxo (por exemplo, após seguir por várias telas para criar um postagem, retornar para a tela do feed após a publicação ser concluída).

Essas situações exemplificam dois conceitos importantes quando tratamos de navegação:

Navegação Programática: permite a navegação “automática” através de gatilhos de código, sem precisar necessariamente de um clique em algum link.

Navegação Profunda: quando existem vários níveis de telas empilhadas em um mesmo fluxo, e buscamos retornar facilmente à raiz ou acessar pontos específicos dessa estrutura.

Com isso, fica claro que, quanto maior a complexidade do aplicativo em termos de quantas telas percorremos para concluir uma ação, mais difícil se torna gerir esse fluxo e permitir o retorno com facilidade. E é aí que entra o NavigationPath.

Entendendo a pilha (stack)

Para entender o NavigationPath, precisamos lembrar o conceito de pilha (stack): uma estrutura onde o último elemento a entrar é o primeiro a sair (LIFO: Last In, First Out). Como o nome intui, ela funciona como uma pilha de pratos: só conseguimos adicionar ou retirar elementos no topo.

• Empilhar (push): abrir uma nova tela coloca-a no topo da pilha.
• Desempilhar (pop): voltar remove a tela do topo.
• Raiz: a tela na base, que nunca sai da pilha.

Como funciona o NavigationPath?

NavigationPath é um tipo introduzido no iOS 16 (junto com NavigationStack) que representa uma pilha de navegação com tipos apagados (type-erased). Ele guarda os valores que foram “empurrados” (pushed) na navegação, permitindo que você controle a pilha de forma programática: adicionar telas, voltar, voltar à raiz, salvar e restaurar o estado.

O grande ponto de NavigationPath é que a navegação passa a ser orientada a dados: você não navega para “views”, e sim para valores, e o SwiftUI decide qual view mostrar para cada tipo de valor. Um detalhe importante: todo valor empilhado precisa ser Hashable.

Na prática, NavigationPath é responsável apenas por armazenar uma lista dos valores que estão sendo empilhados, agora que a navegação acontece através da passagem destes valores. Para que o fluxo funcione adequadamente, ele atua em conjunto com outros elementos:

• NavigationStack(path:) exibe a pilha e a mantém sincronizada com o path.
• .navigationDestination(for:) diz qual tela corresponde a cada tipo de valor.

struct ContentView: View {
    @State private var path = NavigationPath()

    var body: some View {
        NavigationStack(path: $path) {
            Button("Ver receita") {
                path.append(Receita(id: 1, titulo: "Moqueca de palmito"))
            }
            .navigationDestination(for: Receita.self) { receita in
                ReceitaDetalheView(receita: receita)
            }
        }
    }
}

struct Receita: Hashable {
    let id: Int
    let titulo: String
}

Neste trecho de código, o path é a variável observada que inicializa um NavigationPath. Dentro do body, criamos a pilha com NavigationStack(path: $path), passando nossa variável criada anteriormente. Ao clicar no botão, ocorre a ação de adicionar um valor (a receita) ao path, que funciona como o push na pilha. O carregamento da View correspondente ao valor só é tratado na .navigationDestination que recebe o tipo de valor de Receita.

Operações básicas

Como visto anteriormente, a operação em uma pilha permite adicionar e remover valores do topo, ou esvaziá-la completamente. Elas atuam em cima de uma variável que inicializou o NavigationPath, que aqui chamaremos de path. Abaixo são demonstradas as operações possíveis.

path.append(valor)        // push: empilha uma tela
path.removeLast()         // pop: volta uma tela
path.removeLast(2)        // volta duas telas
path.count                // quantas telas estão empilhadas
path = NavigationPath()   // esvazia tudo: volta à raiz

Aplicação prática para navegação profunda

Retornando à questão inicial, ainda precisamos entender como esses tipos de dados e manipulações servem para solucionar o problema da navegação profunda. A fim de explicar sua aplicação prática, considere o seguinte contexto: temos uma tela de Home com botões que direcionam para fluxos diferentes, a saber: publicar uma receita, publicar um evento ou acessar um perfil.

Começamos criando os possíveis valores do caminho através de um enum hashable, para permitir que esses valores sejam empilhados. Ainda não estamos tratando das views destes valores, e sim apenas declarando os fluxos de navegação possíveis.

enum Rota: Hashable {
  case novaReceita
  case novoEvento
  case perfil(usuario: String)
}

Depois, um único lugar decide qual view corresponde a cada rota:

struct HomeView: View {
    
    @State private var path = NavigationPath()
    
    var body: some View {
        NavigationStack(path: $path) {
            VStack(spacing: 20) {
                
                Button("Publicar nova receita") {
                    path.append(Rota.novaReceita)
                }
                
                Button("Publicar novo evento") {
                    path.append(Rota.novoEvento)
                }
                
                Button("Visualizar perfil") {
                    path.append(Rota.perfil(usuario: "Fulaninho"))
                }
            }
            .navigationDestination(for: Rota.self) { rota in
                destino(para: rota)
            }
        }
    }
    
    // unifica a gestão da rota de destino com um único switch
    @ViewBuilder
    private func destino(para rota: Rota) -> some View {
        switch rota {
        case .novaReceita:
            CriarReceitaFlowView(path: $path)
        case .novoEvento:
            CriarEventoFlowView(path: $path)
        case .perfil(let usuario):
            PerfilView(usuario: usuario)
        }
    }
}

Cada view filha fica responsável por gerenciar seu próprio fluxo na pilha e, ao final, pode retornar para a tela inicial:

struct PublicarReceitaView: View {
    @Binding var path: NavigationPath

var body: some View {
        VStack(spacing: 24) {
            Text("Tudo certo com sua publicação?")
            Button("Publicar") {
                // envia o post
                path = NavigationPath()   // volta direto para a Home
            }
        }
        .navigationTitle("Publicar receita")
    }
}

Observações

• Um erro comum é adicionar novas NavigationStacks nas views filhas. Isso quebra o funcionamento pretendido do path, pois a view passa a empilhar seus valores nessa nova pilha e perde o acesso à anterior que a chamou.
• Aqui, estamos chamando FlowViews como views genéricas que direcionam para outras telas de cada fluxo. A PublicarReceitaView representa uma última tela desse fluxo, que permite voltar à Home.

Uso associado com arquitetura MVVM

No exemplo anterior, abstraímos os detalhes de funcionamento de cada FlowView. No entanto, é relevante entender como isso tudo pode ser adaptado para um desenvolvimento com arquitetura MVVM ou semelhante. Nesse contexto, não é desejável que cada tela do fluxo conheça e manipule a pilha de navegação. Em vez disso, a view que possui o path entrega uma função de conclusão, e o fluxo apenas avisa que terminou.

Adicionamos a função de concluir na view pai, e ela será passada pelas próximas telas.

// HomeView.swift

enum Rota: Hashable {
    
    case novaReceita
    case novoEvento
    case perfil(usuario: String)
}


struct HomeView: View {
    
    @State private var path = NavigationPath()
    
    var body: some View {
        NavigationStack(path: $path) {
            VStack(spacing: 20) {
                
                Button("Publicar nova receita") {
                    path.append(Rota.novaReceita)
                }
                
                Button("Publicar novo evento") {
                    path.append(Rota.novoEvento)
                }
                
                Button("Visualizar perfil") {
                    path.append(Rota.perfil(usuario: "Fulaninho"))
                }
            }
            .navigationDestination(for: Rota.self) { rota in
                destino(para: rota)
            }
        }
    }
    
    // esta função será chamada nas views filhas para esvaziar a pilha
    private func concluirCriacao() {
     path = NavigationPath()
    } 
    
    @ViewBuilder
    private func destino(para rota: Rota) -> some View {
        switch rota {
        case .novaReceita:
            CriarReceitaFlowView(aoConcluir: concluirCriacao)
        case .novoEvento:
            CriarEventoFlowView(aoConcluir: concluirCriacao)
        case .perfil(let usuario):
            PerfilView(usuario: usuario)
        }
    }
}

Na FlowView, inicializamos com a ViewModel correspondente e com a função de retorno para a view pai:

struct CriarReceitaFlowView: View {
    
    @State private var viewModel: CriarReceitaViewModel
    
    // inicialização da função de conclusão
    init(aoConcluir: @escaping () -> Void) {
        let viewModel = CriarReceitaViewModel()
        viewModel.aoConcluir = aoConcluir
        _viewModel = State(initialValue: viewModel)
    }
    
    
    var body: some View {
        
        // chama a tela correspondente a cada etapa definida no viewModel
        Group {
            switch viewModel.etapa {
            case .criar:        CriarReceitaView()
            case .ingredientes: IngredientesReceitaView()
            case .preparo:      ModoDePreparoView()
            case .detalhes:     PreparoReceitaView()
            case .publicar:      PublicarReceitaView()
            // outras telas de fluxo...
            }
        }
        .environment(viewModel) // permite que viewModel seja acessada por qualquer view filha
    }
}

E, ao concluir, chamamos a função aoConcluir() quando quisermos encerrar o fluxo e voltar para a tela inicial.

// CriarReceitaViewModel.swift

@Observable
final class CriarReceitaViewModel {
    var etapa: Etapa = .criar

    var aoConcluir: (() -> Void)? // declara a função de concluir

    func publicar() async {
        // envia a receita...
        aoConcluir?()   // avisa a view dona do path que o fluxo terminou
    }
}

Desta maneira, obtém-se um desenvolvimento mais limpo, com menor acoplamento entre telas e respeito ao princípio de responsabilidade única, o que contribui para facilitação da testabilidade e escalabilidade.

Essa é apenas uma maneira de lidar com a navegação em SwiftUI, mas você pode se sentir livre para adaptar para necessidades específicas do seu projeto. Uma prática interessante para modularizar ainda mais as funcionalidades seria criar uma classe Router unificando todas as operações aplicáveis à pilha, de modo que cada viewModel fica apenas responsável por instaciar o Router.

Fontes

• NavigationPath | Apple Developer Documentation
• Understanding the navigation stack | Apple Developer Documentation
• Taking control of your navigation in SwiftUI with NavigationPath

Navegação profunda em SwiftUI: entenda como utilizar NavigationPath para lidar com fluxos de telas… was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

E u sempre tive uma dificuldade muito grande de compreender como funcionavam os comandos de Git, tudo sempre pareceu muito abstrato e difícil de absorver. Sempre precisava perguntar para meus colegas qual era o próximo passo. Até que um dia resolvi explicar pra mim mesma como se tivesse 5 anos e, de repente, tudo pareceu mais simples do que realmente era.

1. Introdução: o que é Git?

O Git é um sistema de controle de versões, ou seja, ele armazena todas as versões de um software, cada mudança feita ao longo do processo de desenvolvimento é mapeada. Isso é fundamental para a construção de um código colaborativo, se uma pessoa sem querer causou um bug no projeto, é possível facilmente retornar para a versão prévia.

Porém, para usufruir desse sistema é preciso entender os comandos que você precisa direcionar à sua máquina, o que muitas vezes pode parecer confuso, principalmente, para quem está iniciando sua trajetória como pessoa desenvolvedora. Para mim essas instruções sempre ficaram muito abstratas e vagas, foi aí que decidi utilizar a abordagem de explicar para mim mesma com o método “explain like i'm 5” (como se tivesse 5 anos).

2. “Explain Like I’m Five”: como funciona essa abordagem?

O método de explicar para alguém como se essa pessoa tivesse 5 anos surgiu na comunidade do Reddit, através do subreddit: “Explain like I’m five”; com o intuito de que as pessoas fizessem perguntas complexas e recebessem repostas simples e esclarecedoras livres de julgamento, como se os usuários estivessem explicando para uma criança. Entretanto, isso não implica que precisam ser respostas rasas e infantilizados, geralmente as publicações recorrem a analogias e simplificações como meio de aproximar pessoas de assuntos que possam parecer inicialmente intimidadores e de difícil compreensão.

E foi pensando nisso que cheguei a seguinte pergunta: E se aprender Git fosse como construir um castelo de LEGO?

3. Comandos do Git: vamos construir um castelo de LEGO?

Imagine que você está no jardim de infância. Durante o recreio, você e seus amigos decidem começar um projeto muito importante: construir o maior e mais incrível castelo de LEGO que a escola já viu. Depois de muito trabalho, vocês finalmente terminam a base do castelo. Como todo bom projeto, vocês querem garantir que ninguém estrague o que já foi construído.

3.1 Git init: o começo de tudo

Antes de continuar, vocês decidem criar um diário para registrar o desenvolvimento do castelo. Nesse diário, poderão guardar informações sobre cada etapa importante da construção.

É exatamente essa a ideia do comando: git init

Ele inicializa um repositório Git, permitindo que o histórico de alterações do projeto comece a ser registrado. Agora vocês têm um sistema preparado para acompanhar a evolução do castelo!

3.2 Main: nosso castelo principal

A base do castelo está pronta e vocês decidem que ela será o ponto de partida para as próximas construções. Vamos chamar essa linha principal de desenvolvimento de main. Ela representa a versão principal do projeto, a partir da qual podemos criar outras linhas de desenvolvimento.

Porém o recreio está acabando e ainda faltam muitas coisas. Vocês precisam construir torres, muralhas e até um navio para proteger o castelo. Como fazer tudo isso sem correr o risco de estragar a construção principal?

3.3 Git branch: cada ideia no seu próprio espaço

Para continuar o projeto, vocês decidem criar espaços separados de construção. Dessa maneira, cada pessoa pode experimentar novas ideias sem modificar diretamente o castelo principal.

Você fica responsável por duas tarefas: construir a torre leste e desenvolver um navio. Para organizar o trabalho, cria duas branches:

git branch torre-leste

git branch navio

Uma branch é uma linha de desenvolvimento que permite trabalhar em alterações separadamente. Entretanto, é importante lembrar que as branches não pertencem necessariamente a pessoas diferentes. Você pode criar várias branches para desenvolver funcionalidades distintas, assim como várias pessoas podem colaborar em uma mesma branch.

3.4 Git switch: mudando de construção

Você decide começar pela torre leste. Para entrar na branch correspondente, utiliza:

git switch torre-leste

Agora você pode trabalhar nas alterações dessa branch.

3.5 Git stash: guardando as peças para depois

Imagine que você está montando a torre leste. Existem peças espalhadas por todos os lados, algumas paredes estão pela metade e você ainda não terminou essa etapa. No entanto, como você decidiu começar o navio, não quer perder o progresso da torre, mas também não quer registrar uma etapa inacabada no histórico principal da construção. Então pega uma caixa, coloca suas peças e instruções provisórias lá dentro e guarda tudo para continuar depois.

Essa caixa é o nosso git stash

Esse comando guarda temporariamente as alterações locais que ainda não foram commitadas, deixando a área de trabalho limpa para outras atividades. Agora você pode mudar para a branch do navio:

git switch navio

Depois de trabalhar no navio, decide voltar para a torre:

git switch torre-leste

Mas espere! Onde estão as peças que você tinha guardado? Elas continuam na caixa! Para recuperá-las, basta utilizar:

git stash pop

Esse comando reaplica as alterações guardadas e, se a operação for bem-sucedida, remove a entrada correspondente do stash. Agora você pode continuar a construção exatamente de onde parou!

Obs: Na prática, nem toda troca de branch exige um stash. Ele é útil quando precisamos guardar temporariamente alterações que poderiam interferir na mudança de contexto.

4. Git commit: uma fotografia para o nosso diário

Depois de muito trabalho, você finalmente termina a torre leste. Ela ficou incrível. Mas como garantir que essa etapa da construção fique registrada?Lembra do diário que criamos no início? Chegou a hora de utilizá-lo.

Esse é o momento de registrar essa etapa da construção. Você tira uma fotografia da torre e escreve uma pequena descrição no diário: “Torre leste finalizada”. No Git, fazemos isso utilizando:

git commit -am "Finaliza a torre leste"

Obs: -am, o "a" vem de add e o "m" de message

O commit registra um novo ponto no histórico do projeto com o conteúdo preparado na staging area. Assim, podemos acompanhar como o castelo evoluiu ao longo do tempo. E, se algo der errado no futuro, teremos um histórico que poderá nos ajudar a recuperar versões anteriores.

5. Git merge: juntando nossas construções

Depois de vários recreios, a torre leste finalmente está pronta. Mas existe um problema: ela foi desenvolvida em uma branch separada e ainda não foi incorporada à linha principal do castelo.

Chegou a hora de juntar tudo! Primeiro, você volta para a branch principal:

git switch main

Depois, utiliza:

git merge torre-leste

Esse comando integra as alterações da branch torre-leste à branch atual, main. É como pegar a torre que você construiu separadamente e incorporá-la ao castelo principal. Agora todos podem aproveitar a nova construção.

Mas e se duas pessoas tiverem modificado a mesma parte do castelo de maneiras diferentes?

6. Merge conflict: quando duas ideias não combinam

Imagine que você e seu amigo Pedro estavam trabalhando em branches diferentes. Você decidiu que a entrada do castelo deveria ter uma porta vermelha. Pedro, por outro lado, decidiu que a mesma porta deveria ser azul. Quando vocês tentam juntar as alterações, surge uma dúvida: Afinal, qual cor a porta deve ter?

Em determinadas situações, o Git não consegue decidir automaticamente como combinar alterações incompatíveis. Isso é chamado de merge conflict.

E, ao contrário do que pode parecer, um conflito não significa que seu projeto foi destruído! Significa apenas que o Git precisa da sua ajuda para decidir como resolver determinadas alterações. Vocês podem conversar e decidir manter a porta vermelha, a azul ou até criar uma solução completamente diferente.

O importante é lembrar: conflitos fazem parte do desenvolvimento colaborativo e não precisam ser motivo de pânico.

7. Git push, Git fetch e Git pull: compartilhando o castelo com os amigos

Até agora, você aprendeu a criar branches, registrar alterações e integrar diferentes linhas de desenvolvimento. Entretanto, existe um último problema. Você construiu uma torre incrível em casa, só que seus amigos ainda não conseguem ver as alterações que estão no seu computador.

Para compartilhar o trabalho, vocês utilizam um repositório remoto, que pode estar hospedado no GitHub. Pense nele como um espaço compartilhado onde o projeto e seu histórico podem ser armazenados e acessados pela equipe.

7.1 Git push: enviando suas alterações

Você terminou sua parte da construção e quer compartilhar os novos registros com seus amigos. Para enviar seus commits ao repositório remoto, pode utilizar:

git push origin main

Nesse exemplo, origin é o nome do repositório remoto e main é a branch cujos commits você deseja enviar. É como atualizar o projeto compartilhado com as novas etapas que você registrou.

A depender de como você criou seu repósitorio, se foi direto em uma plataforma de repositórios Git, como o Github, e já tem ela clonada em sua máquina (ver sobre git clone se você não conhece), o comando git push origin main vai funcionar, entretanto, se você ainda não tem essa branch no Github (remoto) será preciso colocar argumentos: git push origin -u main ou git push origin — upstream main (-u e — upstream) sao as mesmas coisas.

Depois que você usou o -u pela primeira vez, as duas branches já estão conectadas (localmente e remota). A partir daí, basta digitar git push, pois o Git já sabe que deve enviar as alterações para a origin na branch correspondente automaticamente, ou seja, não será mais preciso o origin -u no comando.

Obs: O uso do origin é só na primeira vez.

7.2 Git fetch: descobrindo as novidades do castelo

Imagine que, enquanto você estava em casa construindo sua torre, seus amigos continuaram trabalhando no castelo da escola. Pedro construiu uma muralha, Maria adicionou um jardim e João decidiu modificar a entrada principal.

No entanto, você ainda não sabe de nada disso. Curioso para descobrir o que aconteceu durante sua ausência, você pede aos seus amigos que enviem as informações sobre as últimas modificações do castelo.

É exatamente isso que o git fetch faz!

git fetch origin

Esse comando busca as atualizações do repositório remoto e atualiza as referências remotas armazenadas no seu computador, sem modificar automaticamente os arquivos em que você está trabalhando. É como receber fotografias das novas construções dos seus amigos, mas sem adicionar nenhuma dessas mudanças ao seu próprio castelo.

Assim, você consegue descobrir o que mudou antes de decidir se deseja incorporar as novidades ao seu projeto. Mas e se você quiser trazer essas alterações para a sua construção?

É aí que entra o nosso próximo comando!

7.3 Git pull: trazendo as novidades para o castelo

Agora que você já sabe o que seus amigos construíram, decide que também quer incorporar essas alterações ao seu castelo.

Para isso, utiliza:

git pull origin main

Diferentemente do git fetch, o git pull não apenas busca as atualizações do repositório remoto, mas também tenta integrá-las à sua branch atual. É como receber as fotografias das construções dos seus amigos e, em seguida, atualizar seu próprio castelo para incluir as novidades. De maneira simplificada, podemos pensar que:

Git fetch = descobrir o que mudou.

Git pull = buscar as mudanças e tentar incorporá-las ao seu trabalho.

E sabe o mais interessante? O git pull já realiza uma operação de fetch antes de integrar as alterações, ou seja, você não precisa executar os dois comandos em sequência obrigatoriamente.

No final das contas, o git pull é um git fetch seguido de um git merge, ele busca e tenta mesclar (verifica se terá conflito)

8. Afinal, Git é tão complicado assim?

Quando comecei a aprender Git, eu tentava decorar comandos sem compreender exatamente o que eles faziam. Sabia que precisava utilizar git commit ou git push, mas nem sempre entendia o motivo. E acho que esse é um dos maiores desafios de aprender ferramentas de desenvolvimento: muitas vezes tentamos memorizar soluções antes de compreender os problemas que elas resolvem.

A analogia do castelo de LEGO não explica todas as particularidades do Git, mas nos ajuda a visualizar o papel de cada comando dentro de um processo de desenvolvimento. E, quando entendemos o que está acontecendo, aqueles comandos que antes pareciam tão abstratos começam a fazer muito mais sentido.

No fim das contas, aprender Git não precisa ser sobre decorar uma sequência de instruções. Pode ser simplesmente sobre entender como construir, registrar, experimentar e compartilhar algo com outras pessoas. Mesmo que esse algo seja apenas um castelo de LEGO.

Contato:

• luisamsimoes - Overview
• Luísa Simões - Recife, Pernambuco, Brazil | Professional Profile | LinkedIn

Explicando comandos de Git como se você tivesse 5 anos was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Existe algo que fica à espreita em todos os projetos que tem a pretensão de serem lançados a público. Você passa meses idealizando uma solução, prototipa, coda, se estressa com o versionamento até que finalmente está pronto, e aí o monstro aparece. Quem diria, a solução que você projetou para pessoas PRECISA alcançar pessoas, e automaticamente se torna necessário promover e defender a sua proposta com unhas e dentes em diferentes situações, com uma boa estratégia de marketing, e apresentações com um bom pitch de produto.

É por meio do pitch que as pessoas terão o primeiro contato com a sua ideia, em poucos minutos você precisa comunicar qual é o problema, quais são as pessoas afetadas por ele, a solução proposta e como ela agrega valor para esses usuários, tudo isso com uma boa linearidade narrativa, dados relevantes e muito, mas muito ensaio.

Além de uma boa linha narrativa, um bom pitch precisa de apoio visual para comunicar com profissionalismo, credibilidade, maior precisão e interatividade o seu produto, e isso é feito normalmente através de apresentações com slides.

Quando comecei a fazer apresentações foi de forma bem básica em situações mais acadêmicas seguindo um padrão bastante ABNT, muito texto, informações em tópicos com marcadores, um formato bastante quadrado com uma hierarquia bem padrão de título, corpo de texto e imagens. Formatos assim servem mais como forma de apoio ao apresentador do que para ser algo que de fato acrescente na experiência de quem está assistindo.

Apresentações de Slides em pitches servem para apoiar a sua fala, simplificar conceitos e dados, além, é claro, de chamar atenção e causar impacto, por isso devem ser sucintos, interessantes, dinâmicos, interativos e estéticamente satisfatórios. Através do conhecimento dos fundamentos de design alcançar esses objetivos fica mais simples.

Hierarquia, contraste e escala entre os elementos, é o que vai comunicar o que você deseja passar, destacar pontos importantes e tornar a sua apresentação interessante ao público.

É importante estar atento à algumas coisas para ter um bom resultado na construção desse tipo de material:

1. Faça os slides com base no seu roteiro de apresentação, dessa forma fica tudo bem sincronizado e de fato fomentará a sua performance.

2. Tenha uma identidade aplicada, utilize dos elementos visuais que tem a ver com o seu produto e mantenha uma unidade em todas as páginas (cores, texturas, imagens).

3. Alimente sua narrativa com imagens, em alguns momentos uma imagem fala mais que mil palavras.

4. Use e abuse de escala: quer dar ênfase em algum contexto ou tem uma imagem que é crucial para a sua fala? Dê a ela o devido espaço, aumente seu tamanho, vaze o conteúdo ou o torne o centro da página.

5. Invés de usar marcação de tópicos utilize outras formas de demarcar importância (containers, opacidade, tamanho, pesos de fonte).

6. Descondense informações, caso necessário divida o tópico em mais de um slide:

7. Utilize mockups

Além disso, há outras informações que merecem uma atenção especial nas suas páginas.

Vem comigo: você encontra uma pesquisa massa que dá credibilidade ao seu projeto e a transcreve para o slide com texto puro de 3 linhas em um slide. As pessoas que estão vendo a apresentação desviam a atenção lendo o que tem no slide, desfocando da sua fala, ou até mesmo perdem o interesse no que está na tela.

Transformar dados em uma informação mais impactante e acessível é uma grande habilidade do design da informação e infografia que prezam por descomplicar tópicos e temas complexos ou difíceis de serem abordados, por meio de representações visuais ao invés de texto. E é aí que você pode usar toda a sua criatividade para transformar algo cansativo em um momento de impacto na sua apresentação.

Brincar com elementos, ilustrações, materiais, escalas e senso de quantidade são ideias muito bem-vindas. Veja alguns exemplos abaixo: (Os mesmos conceitos de design estão presentes nessa fase, além da gestalt que é aplicado quando estamos trabalhando com a visualização de elementos agrupados.)

1. Dados através de elementos gráficos

2. Números grandes e expressivos

3. Resuma a informação e mostre apenas o essencial (não esqueça de mencionar a fonte).

Essas são algumas dicas que podem não ser milagrosas mas são ótimas práticas para avaliar se a sua apresentação está comunicando bem a ideia do seu produto. Quando for construir o seu material não esqueça também de procurar por boas referências para ter mais ideias de como representar seu roteiro.

• View of Infografia: Conceito e Prática
• What is a Pitch Deck? Examples, Tips and Templates (2021)

Infografia e pitch para quem não é designer was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tudo muda quando só temos poucos minutos para contar nossa história. É preciso estar preparado para honrá-la quando a oportunidade chegar.

Neste artigo, vamos aprender a desenvolver do zero a estrutura e o raciocínio de um bom pitch, a partir da tão assustadora folha em branco, seja ela uma Chamex ou do Google Docs.

Mas antes, de forma prática, precisamos entender o que é um pitch.

Pitch deck é uma apresentação curta para vender uma ideia, um produto ou um serviço, geralmente realizada para captar recursos de investidores.

Se eu pudesse definir os princípios básicos de um pitch em 3 palavras, diria simples, direto e afiado.

Simples porque precisa ser compreendido por todos.
Direto porque, de forma geral, não teremos tempo para desperdiçar.
Afiado porque sua força está em encontrar o tom da apresentação.

3 passos para começar a construir o seu pitch

1. Pensar para quem é a apresentação: investidor, parceiro ou público final (clientes)? Definir isso será essencial para resolver qual será o tom adotado, além dos argumentos de convencimento. Um pitch para investidor provavelmente será um pouco menos descontraído, enquanto o público final de maneira geral não tem muito interesse em escalabilidade e na projeção de números do seu negócio. É nesse momento que você vai avaliar tudo isso.
2. Escrever tópicos para não deixar nada de fora: pessoalmente, gosto de começar no papel porque me ajuda a pensar, mas você pode fazer isso de forma digital também. O importante é conseguir visualizar os pontos-chave do seu pitch para conferir ao final se contemplou todos.
3. Desenvolver o raciocínio completo: o pitch consiste em apresentar um problema, uma solução e uma chamada para ação. Ou seja, você parte de um ponto A, passa por um ponto B e finaliza em um ponto C. E uma forma muito poderosa de fazer isso é com storytelling.

Ao finalizar esses 3 passos, você deve estar seguro de qual a história você quer contar e para quem, levando em consideração os personagens, os desafios que ele enfrenta, a resolução da história e o que você quer provocar com ela no seu ouvinte.

Finalmente, como desenvolver o pitch?

Você vai precisar escrever tudo que vai ser falado, cada frase, um roteiro da sua apresentação. Não precisa decorar uma “fala” como se fosse um trabalho de escola, mas é necessário conhecer a estrutura narrativa com segurança.

Apresente o problema que você precisou resolver

Antes de revelar qual é a sua ideia, produto ou serviço, comece pensando em um início que prenda a atenção e desperte a curiosidade da audiência para querer saber mais sobre a sua apresentação. Pode ser uma pergunta, uma frase de impacto ou a apresentação de um personagem, por exemplo. Mas isso deve estar atrelado ao problema que você resolveu.

Ancore a solução do problema com dados

Seja específico e mostre dados para mostrar como a sua solução resolve o problema apresentado anteriormente. No caso de um aplicativo para celular, por exemplo, você pode falar sobre as funcionalidades que resolvem uma dificuldade ou uma necessidade do seu usuário.

Finalize com uma chamada para ação

Mais perguntas importantes para se fazer: qual é o objetivo da sua apresentação? O que você deseja que a audiência faça logo após finalizar o seu pitch?

Vamos imaginar que você deseja que a audiência baixe seu aplicativo ou que investidores te procurem para continuar uma conversa de negócios. Como a ideia nessa etapa é facilitar que a ação seja realizada, então, seguindo com esses exemplos, você pode colocar nos slides o QR Code que leve para o aplicativo na loja ou para o contato profissional no WhatsApp Business.

Outra boa prática é terminar o pitch com uma frase de efeito que sintetize a solução que você apresentou, como se fosse um mote ou um slogan.

O ritmo do pitch

Quando você estiver escrevendo o roteiro da sua narrativa, preste atenção no fluxo das informações e nos ganchos entre as frases para não quebrar o ritmo da apresentação.

Evite interrupções como “agora eu vou falar sobre tal assunto…” porque isso não acrescenta nenhuma informação relevante para o público e ainda te faz perder segundos valiosos. Pode ir direto ao tópico, sem medo.

Treinar é a melhor prática antes da apresentação

Training season is not over! Depois de escrever palavra por palavra do seu pitch, a ideia é começar lendo o texto e cronometrando o tempo até se acostumar com a estrutura da apresentação.

É assim que você vai criar intimidade com o texto, adaptar termos que pareçam deslocados e memorizar a estrutura(o que vem antes, o que vai depois) para não se perder. Logo você vai deixar de precisar ler, porque já sabe o que e quando precisa falar.

Essa etapa é importante para fazer ajustes e refinar o seu pitch: se sobrou tempo, você pode incluir mais informações, falar sobre testadores, sobre seu modelo de negócio, funcionalidades e próximos passos. Se faltou tempo, é hora de enxugar o texto, limando tudo que não é essencial para o pitch.

Não esqueça de treinar junto com os slides do pitch para casar sua fala com a parte visual da apresentação!

Dois parágrafos, antes de dar tchau

Ser um bom ouvinte pode te ajudar a entender como funciona um bom pitch. Busque no Youtube vídeos como “1 minute pitch example” para ter referências sobre ritmo, postura, introdução e chamada para uma ação (call to action) ao final, por exemplo.

Além de ter referências, apresentar pitch também é uma questão de prática, então se ele não sair perfeito de primeira, fique tranquilo. Uma carreira é construída a partir de experiências. Aprenda, adapte e repita até melhorar o que deseja.

Antes do primeiro slide: como montar a narrativa do seu Pitch was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ao desenvolver um aplicativo, muitas vezes precisamos de um banco de dados remoto para armazenar os dados dos nossos usuários.
Surge então a dúvida:

• Como atualizar a tela automaticamente quando os dados chegarem?
• Como adicionar animações como shimmering (também conhecido como Skeleton) ou UIProgressView durante o carregamento?
• E, no caso de falha, como exibir um erro claro para o usuário?

Para resolver tudo isso, podemos criar uma variável de estado da tela e atualizá-la conforme cada etapa do processamento no banco.

ViewState

Vamos criar um enum para representar os possíveis estados da view:

enum ViewState {
    case idle
    case loading
    case updating
    case error(Error)
    case success
}

Idle

Ele é o estado que surge logo antes das busca ao banco ser chamada. Nele, podemos deixar a UIView em branco ou exibir apenas os elementos imutáveis — que não dependem dos dados carregados.

Loading e Updating

É nesses estados que a tela fica enquanto o app espera a execução de operações no banco.

Por que dividir em dois? Poderíamos simplesmente utilizar o loading para lidar com todos os tipos de operações de acesso ao banco. Porém, é interessante dividir entre operações de leitura (read) e de modificação ao banco (create, update, delete).

Assim, podemos adicionar animações de shimmering exclusivamente ao estado de loading, e simular o carregamento dos componentes da tela enquanto o app espera a resposta de leituras ao banco.

Já para operações de modificação realizadas pelo usuário, podemos utilizar o updating para adicionar uma animação de carregamento como uma UIProgressView. Assim, o usuário espera a conclusão da operação com um feedback visual claro.

Success

É o caso em que a operação foi concluída com sucesso e a tela está pronta para exibir as informações obtidas. É aqui que vamos atualizar a ViewController com os dados obtidos do banco.

Error

É o estado da tela em que houve algum erro na operação do banco e deve ser repassado para o usuário visualizar na tela.

Para que possamos exibir componentes ou mensagens diferentes para cada tipo de erro, precisamos saber qual erro aconteceu. Para isso, o próprio caso do enum tem um tipo associado em que podemos passar o erro retornado da operação. É por isso que declaramos o caso do enum assim:

case error(Error)

Por exemplo, se houve o erro NetworkFailed:

var viewState = ViewState.error(NetworkFailed)

Incorporando o ViewState nas operações do Banco

Nesse artigo, usarei a arquitetura MVVM. Assim, as funções que fazem operações ao banco estarão na ViewModel, e é nela que vamos gerenciar a nossa variável do tipo ViewState. A UIViewController irá apenas reagir aos diferentes estados.

Para simular, vamos criar um serviço que cria e obtém Tasks. Vamos criar a classe Task:

class TaskModel {
    var name: String
    
    init(name: String) {
        self.name = name
    }
}

Agora, vamos criar um serviço que "obtém" as tarefas:

class TaskService {
    func getTasks() async throws -> [TaskModel] {
        return [
            TaskModel(name: "Tarefa 1"),
            TaskModel(name: "Tarefa 2"),
            TaskModel(name: "Tarefa 3"),
        ]
    }
}

A função acima é assíncrona e gera um erro — que será tratado na ViewModel e retornado para a ViewController exibí-lo.

Vamos então criar a ViewModel:

class ViewModel {
    
    // MARK: Init
    let taskService: TaskService

    init(taskService: TaskService) {
        self.taskService = taskService
    }
    
    // MARK: State
    public var viewState: ViewState = .idle
    
    // MARK: UIData
    public var tasks: [TaskModel] = []

}

Injetamos o TaskService* e inicializamos o viewState no estado idle. Além disso, inicializamos um array de Tasks vazio.

Vamos agora criar a função da ViewModel que chama a TaskService:

func fetchTasks() async {
    viewState = .loading
    
    do {
        self.tasks = try await taskService.getTasks()
        
        viewState = .success
    } catch {
        print("Erro ao obter tarefas: \(error)")
        viewState = .error(error)
    }
}

*Seria mais adequado utilizar um protocolo para injetar os serviços.

Nessa função, inicialmente alteramos o viewState para loading para indicar que estamos no meio de uma operação de leitura.

Depois, chamamos um do/catch pra poder chamar a função getTasks e tratar corretamente o erro. Se não houver erros, o viewState é alterado para .success para indicar que a tela pode ser atualizada com os dados novos. Caso contrário, entrará no catch com um error e irá printar o erro, além de alterar o viewState para .error, passando o erro obtido como tipo associado.

Poderíamos fazer o mesmo para uma operação do tipo createTask, utilizando o estado updating.

UIViewController e UIView

Vamos criar a UIViewController e a UIView:

class TaskViewController: UIViewController {
    
    let taskView: TaskView
    let viewModel: ViewModel
    
    init(taskView: TaskView, viewModel: ViewModel) {
        
        self.taskView = taskView
        self.viewModel = viewModel
        super.init(nibName: nil, bundle: nil)
        
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    // MARK: Lifecycle

    override func viewDidLoad() {
        super.viewDidLoad()
    }
    
    override func loadView() {
        self.view = taskView
    }
    
}

class TaskView: UIView {
    
    // MARK: Init
    init() {
        super.init(frame: .zero)
    
        setupView()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    // MARK: Components
    
    lazy var label: UILabel = {
        let label = UILabel()
        
        label.translatesAutoresizingMaskIntoConstraints = false
        label.font = UIFont.systemFont(ofSize: 18, weight: .bold)
        
        return label
    }()
    
    // MARK: SetupView
    
    func setupView() {
        setupViewsHierarchy()
        setupViewAttributes()
        setupConstraints()
    }
    
    func setupViewsHierarchy() {
        self.addSubview(label)
    }
    
    func setupViewAttributes() {
        
    }
    
    func setupConstraints() {
        NSLayoutConstraint.activate([
            label.topAnchor.constraint(equalTo: safeAreaLayoutGuide.topAnchor),
            label.leadingAnchor.constraint(equalTo: leadingAnchor),
            label.trailingAnchor.constraint(equalTo: trailingAnchor),
            label.bottomAnchor.constraint(equalTo: safeAreaLayoutGuide.bottomAnchor),
        ])
    }
    
}

Nesse formato, a ViewController conhece a ViewModel e a UIView e pode acessar valores e funções de ambas. Assim, podemos obter diretamente as tasks salvas na ViewModel e atualizar nossa UIView quando necessário.

Porém, como que a ViewController saberá quando a ViewModel atualizar seus valores?

A ViewModel precisaria alertar a ViewController de alguma maneira. Porém, a ViewModel não conhece a ViewController, e dessa forma não consegue acessar nada interno a ela. É aqui que entram os Delegates.

Delegate

Um Delegate é uma forma de estabelecer uma comunicação entre dois objetos, permitindo que um objeto chame operações de outro objeto.

No nosso exemplo, a ViewController já conhece a ViewModel, porém a ViewModel não conhece a ViewController. Poderíamos injetar diretamente a ViewController na ViewModel, mas com isso teríamos alguns problemas:

class ViewModel {
    
    let taskService: TaskService
    let viewController: TaskViewController

    init(taskService: TaskService, viewController: TaskViewController) {
        self.taskService = taskService
        self.viewController = viewController
    }
    // ...
}

1. Referência Circular

A ViewController depende da ViewModel para ser inicializada, então se a ViewModel também depender da ViewController, isso criaria um loop.

2. Ciclo de Retenção

Por conta da referência circular acima e da referência forte (sem uso de weak) entre os objetos, ambos se mantém alocados na memória e podem gerar memory leaks.

3. Violação da Arquitetura

Não é ideal que a ViewModel conheça a ViewController diretamente. Ela precisa existir independentemente da implementação da UI. Além disso, bastava que a ViewModel conhecesse apenas funções da ViewController que gerenciam o estado da tela, porém ela também conhece e pode acessar todas as outras funções o que não é adequado.

Para resolver esses problemas, vamos criar um protocolo que vai estabelecer a conexão entre a View e ViewController e incluir apenas as funções que importam para essa comunicação.

A ViewController será o objeto em que são delegadas tarefas (delegado) e por isso implementará o protocolo. Já a ViewModel será o delegador que manda as tarefas e armazenará uma referência ao delegado. A vantagem é que o delegador não conhece quem é o seu delegado, apenas sabe que ele implementa algumas funções.

Vamos criar o protocolo ViewDelegate:

protocol ViewDelegate: AnyObject {
    func didChangeState(state: ViewState)
}

Como queremos reagir de acordo com o ViewState, vamos criar uma função didChangeState. Essa função será chamada pela ViewModel quando o estado mudar mas será implementada na ViewController.

Agora, precisamos adicionar a referência do delegate à ViewModel. Faremos assim:

weak var delegate: ViewDelegate?

A variável é weak e opcional para evitar os problemas de referência circular e ciclo de retenção.

Além disso, precisamos também conectar nosso viewStateà chamada da função didChangeState. Para isso, vamos adicionar um didSet à variável viewState. O que o didSetfaz é chamar a closure dentro dele toda vez que o viewState mudar. No caso, chamaremos a função do delegate para avisar ao nosso delegado que o estado mudou e ele precisa fazer algo.

public var viewState: ViewState = .idle {
    didSet {
        delegate?.didChangeState(state: viewState)
    }
}

Nossa ViewModel ficará assim:

class ViewModel {
    
    // MARK: Delegate
    weak var delegate: ViewDelegate?
    
    // MARK: Init
    let taskService: TaskService

    init(taskService: TaskService) {
        self.taskService = taskService
    }
    
    // MARK: State
    public var viewState: ViewState = .idle {
        didSet {
            delegate?.didChangeState(state: viewState)
        }
    }
    
    // MARK: UIData
    public var tasks: [TaskModel] = []
    
    func fetchTasks() async {
        viewState = .loading
        
        do {
            self.tasks = try await taskService.getTasks()
            
            viewState = .success
        } catch {
            print("Erro ao obter tarefas: \(error)")
            viewState = .error(error)
        }
    }

}

Agora, falta só ajustarmos a nossa ViewController para seguir o protocolo ViewDelegate:

class TaskViewController: UIViewController, ViewDelegate {
    
    let taskView: TaskView
    let viewModel: ViewModel
    
    init(taskView: TaskView, viewModel: ViewModel) {
        
        self.taskView = taskView
        self.viewModel = viewModel
        super.init(nibName: nil, bundle: nil)
        
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    // MARK: Lifecycle

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view.
    }
    
    override func loadView() {
        self.view = taskView
    }
    
    // MARK: ViewState
    
    func didChangeState(state: ViewState) {
        
    }
    
    func updateUI() {
        self.taskView.label.text = "\(viewModel.tasks[0].name)"
    }
    
}

O protocolo requer uma implementação da função didChangeState. Aqui é onde vamos fazer nossa ViewController reagir às mudanças de estado.

Para isso, vamos criar um switch para chamar funções para cada estado:

func didChangeState(state: ViewState) {
    switch state {
    case .idle:
        self.stopAnimations()
    case .loading:
        self.showShimmering()
    case .updating:
        self.showUpdatingScreen()
    case .error(let error):
        self.stopAnimations()
        self.showError(error: error)
    case .success:
        self.stopAnimations()
        self.updateUI()
    }
}

Assim, podemos implementar funções específicas para cada estado e fazer a tela reagir de acordo.

Por fim, ainda precisamos modificar o nosso init para indicar que o delegate da ViewModel é a ViewController:

init(taskView: TaskView, viewModel: ViewModel) {
    
    self.taskView = taskView
    self.viewModel = viewModel
    super.init(nibName: nil, bundle: nil)
    
    viewModel.delegate = self
}

Nossa ViewController fica assim:

class TaskViewController: UIViewController, ViewDelegate {
    
    let taskView: TaskView
    let viewModel: ViewModel
    
    init(taskView: TaskView, viewModel: ViewModel) {
        
        self.taskView = taskView
        self.viewModel = viewModel
        super.init(nibName: nil, bundle: nil)
        
        viewModel.delegate = self
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    // MARK: Lifecycle

    override func viewDidLoad() {
        super.viewDidLoad()
    }
    
    override func loadView() {
        self.view = taskView
    }
    
    // MARK: ViewState
    
    func didChangeState(state: ViewState) {
        switch state {
        case .idle:
            self.stopAnimations()
        case .loading:
            self.showShimmering()
        case .updating:
            self.showUpdatingScreen()
        case .error(let error):
            self.stopAnimations()
            self.showError(error: error)
        case .success:
            self.stopAnimations()
            self.updateUI()
        }
    }
    
    func stopAnimations() {
        hideShimmering()
        hideUpdatingScreen()
    }
    
    func showShimmering() {
        // adiciona shimmering
    }
    
    func hideShimmering() {
        // remove shimmering
    }
    
    func showUpdatingScreen() {
        // adiciona progress view
    }
    
    func hideUpdatingScreen() {
        // remove progress view
    }
    
    func showError(error: Error) {
        // exibe os erros
    }
    
    func updateUI() {
        // atualiza dados da tela
    }
    
}

Assim, podemos gerenciar de forma simples os diferentes estados da tela e fazer nossa ViewController reagir a eles automaticamente.

Delegates e ViewState: gerenciando estados da tela em UIKit was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Durante o desenvolvimento do nosso aplicativo, meu time e eu nos deparamos com a necessidade de compartilhar uma versão do app já populada com dados via GitHub.

Isso era essencial, pois o volume de dados iniciais era alto e recriá-los manualmente a cada build seria inviável. No entanto, o Core Data, por padrão, não armazena os dados persistidos diretamente no projeto — eles ficam salvos localmente no ambiente do simulador ou dispositivo.

Diante desse desafio, surgiu a necessidade de encontrar uma solução prática e eficiente. A ideia que me ocorreu foi rastrear onde o Core Data armazena suas informações, extrair esses dados e configurá-los para serem pré-carregados automaticamente na inicialização do app.

Este artigo tem justamente o objetivo de servir como um guia completo para desenvolvedores que estejam enfrentando esse mesmo cenário.

Passo 1: Entendendo onde o Core Data salva os dados

Quando você usa o Core Data no iOS, o sistema armazena os dados em arquivos SQLite, normalmente localizados na pasta Application Support do sandbox da aplicação. Esses arquivos não ficam visíveis no seu projeto Xcode — e é por isso que, ao compartilhar o app via GitHub, os dados não são enviados junto.

Uma vez que você já esteja com o BD populado. Para localizar os arquivos .sqlite, .sqlite-wal e .sqlite-shm, basta adicionar este print no seu AppDelegate.swift:

let paths = NSSearchPathForDirectoriesInDomains(.applicationSupportDirectory, .userDomainMask, true)
print("📂 Caminho do Application Support: \(paths.first ?? "Caminho não encontrado")")

💡 Esse código imprime o caminho do diretório onde o Core Data salva os dados da aplicação, permitindo que você acesse os arquivos diretamente via Finder.

Agora:

1. Rode o app no simulador.
2. Copie o caminho impresso no console.
3. No Finder, use o menu Ir → Ir para a pasta… (Shift + Command + G) e cole o caminho.

Lá você verá os arquivos:

• DataBase.sqlite
• DataBase.sqlite-wal
• DataBase.sqlite-shm

Perfeito, uma vez que você tenha encontrado. Esses são os três arquivos que você precisa para compartilhar seu banco de dados.

Passo 2: Exportando o banco do simulador

Agora que você já sabe onde o Core Data salva os arquivos, vamos automatizar a exportação com um script, bash. Assim, você pode copiar facilmente os arquivos .sqlite direto do simulador para uma pasta dentro do seu projeto Xcode (ex: DataBaseResources).

📄 Crie um script chamado copiar_sqlite_para_DataBaseResources.sh

#!/bin/bash

# CONFIGURAÇÃO — Altere conforme necessário
BUNDLE_ID="Gabriel.plantei"
DEST_FOLDER="./DataBaseResources"

# PASSO 1 — Descobre o UDID do simulador atual
UDID=$(xcrun simctl list devices booted | grep -oE "[A-F0-9\\-]{36}")

if [[ -z "$UDID" ]]; then
  echo "❌ Nenhum simulador está rodando. Inicie o app no simulador antes de continuar."
  exit 1
fi

echo "🟢 Simulador ativo: $UDID"

# PASSO 2 — Localiza o container de dados do app
APP_PATH=$(xcrun simctl get_app_container "$UDID" "$BUNDLE_ID" data)

if [[ ! -d "$APP_PATH" ]]; then
  echo "❌ Caminho do app não encontrado. Verifique o bundle ID e se o app já foi executado no simulador."
  exit 1
fi

# PASSO 3 — Define a pasta origem dos arquivos
SOURCE_PATH="$APP_PATH/Library/Application Support"

# PASSO 4 — Cria destino e copia os arquivos
mkdir -p "$DEST_FOLDER"

for EXT in sqlite sqlite-shm sqlite-wal; do
  cp "$SOURCE_PATH/DataBase.$EXT" "$DEST_FOLDER/DataBase.$EXT" && echo "✅ Copiado: DataBase.$EXT"
done

echo "🎉 Banco exportado com sucesso para $DEST_FOLDER"

Obs: lembre-se de colocar o BUNDLE_ID correto do seu projeto e rodar o simulador do seu projeto.

🛠️ Como rodar:

0. No terminal entre na pasta do seu projeto

1. Dê permissão de execução:

chmod +x copiar_sqlite_para_DataBaseResources.sh

2. Execute o script

./copiar_sqlite_para_DataBaseResources.sh

Esse script vai:

• Identificar o simulador rodando;
• Localizar o diretório de dados da aplicação;
• Copiar os 3 arquivos essenciais do Core Data;
• Colocá-los na pasta DataBaseResources, dentro do seu projeto.

Caso você não queira usar a pasta DataBaseResources, basta copiar para dentro de outra pasta, no meu caso, usei a Model. Agora:

1. Agora vá em Add Files to “projeto”,

2. Selecione esses 3 arquivos

3. Agora adicione ao seu projeto

💡 Não se esqueça de adicionar os arquivos ao Xcode, marcando a opção “References files in place” e incluindo no target principal do app.

Passo 3: configurando o carregamento automático do BD

Depois de fazer os passos anteriores, vamos configurar o carregamento automático.

O que vamos fazer:

• Verificar se já existe um banco na pasta Application Support;
• Se não existir, copiar os arquivos .sqlite que estão no bundle para essa pasta;
• Somente após isso inicializar o Core Data.

Por que isso é importante?

Se o BD for inicializado antes da cópia, o Core Data cria um novo banco vazio — e ignora os arquivos que você incluiu no projeto. Por isso, a ordem correta é essencial.

OBS: Nesse passo irei explicar detalhadamente a lógica do código, caso você não esteja com muito tempo, pule para o passo 4, onde tem o código final.

Caso você tenha ficado, vamos lá! Para fins didáticos, irei assumir que esteja iniciando em CoreData.

📦 Declaração de propriedades

static let shared = DataBase()
let container: NSPersistentContainer
var viewContext: NSManagedObjectContext

• static let shared: cria uma instância única da classe DataBase (Singleton)DataBase.shared, para ser usada em qualquer parte do app.
• let container: armazena o NSPersistentContainer. responsável por carregar e salvar o modelo.
• var viewContext: acesso rápido para leitura e gravação

🔒 Inicializando o construtor

private init() {
    Self.preloadDatabaseIfNeeded()
    container = NSPersistentContainer(name: "DataBase")
    container.loadPersistentStores { _, error in
        if let error = error as NSError? {
            fatalError("❌ Erro ao carregar o Core Data: \(error), \(error.userInfo)")
        } else {
            print("✅ Core Data carregado com sucesso.")
        }
    }
}

• self.preloadDatabaseIfNeeded(): garante que o banco pré-populado seja copiado antes de abrir.
• NSPersistentContainer(name: "DataBase)": cria o container com base no modelo .xcdatamodeld.
• .loadPersistentStores: carrega o banco, se falhar, encerra com erro; se funcionar, exibe sucesso no log.

👉 Função de pré-carregamento

 static func preloadDatabaseIfNeeded() {
        let fileManager = FileManager.default

        let supportURL = try! fileManager.url(/service/for: .applicationSupportDirectory,
                                              in: .userDomainMask,
                                              appropriateFor: nil,
                                              create: true)

        let sqlitePath = supportURL.appendingPathComponent("DataBase.sqlite")

        if !fileManager.fileExists(atPath: sqlitePath.path) {
            print("📦 Copiando banco pré-populado...")

            guard let sqliteSrc = Bundle.main.url(/service/forresource: "DataBase", withExtension: "sqlite"),
                  let shmSrc = Bundle.main.url(/service/forresource: "DataBase", withExtension: "sqlite-shm"),
                  let walSrc = Bundle.main.url(/service/forresource: "DataBase", withExtension: "sqlite-wal") else {
                print("❌ Arquivos .sqlite não encontrados no bundle.")
                return
            }

            do {
                try fileManager.copyItem(at: sqliteSrc, to: sqlitePath)
                try fileManager.copyItem(at: shmSrc, to: supportURL.appendingPathComponent("DataBase.sqlite-shm"))
                try fileManager.copyItem(at: walSrc, to: supportURL.appendingPathComponent("DataBase.sqlite-wal"))

                print("✅ Banco copiado com sucesso para Application Support.")
            } catch {
                print("❌ Erro ao copiar banco: \(error)")
            }
        } else {
            print("✔️ Banco já existe. Nenhuma cópia é necessária.")
        }
    }

• Verifica se o banco de dados já existe no Application Support.
• Se não existir, copia os arquivos .sqlite, .sqlite-shm e .sqlite-wal do bundle.
• Garante que o app use um banco pré-populado já na primeira execução.
• Evita cópia duplicada se o banco já estiver lá.

💾 Salvando o Contexto

func saveContext() {
    let context = container.viewContext
    if context.hasChanges {
        do {
            try context.save()
            print("✅ Alterações salvas no banco.")
        } catch {
            print("❌ Erro ao salvar contexto: \(error)")
        }
    }
}

• Verifica se há alterações no viewContext (dados em memória).
• Se houver, tenta salvar essas alterações no banco SQLite.
• Exibe logs indicando sucesso ou erro durante a operação.

Obs: É essencial chamar essa função após criar, editar ou deletar dados no Core Data para garantir persistência.

Passo 4: Código final

import Foundation
import CoreData

final class DataBase {

    static let shared = DataBase()
    let container: NSPersistentContainer

    var viewContext: NSManagedObjectContext {
        return self.container.viewContext
    }

    private init() {
        // ⚠️ Copiar banco antes de carregar o Persistent Store
        Self.preloadDatabaseIfNeeded()

        container = NSPersistentContainer(name: "DataBase")
        container.loadPersistentStores { _, error in
            if let error = error as NSError? {
                fatalError("❌ Erro ao carregar o Core Data: \(error), \(error.userInfo)")
            } else {
                print("✅ Core Data carregado com sucesso.")
            }
        }
    }

    static func preloadDatabaseIfNeeded() {
        let fileManager = FileManager.default

        let supportURL = try! fileManager.url(/service/for: .applicationSupportDirectory,
                                              in: .userDomainMask,
                                              appropriateFor: nil,
                                              create: true)

        let sqlitePath = supportURL.appendingPathComponent("DataBase.sqlite")

        if !fileManager.fileExists(atPath: sqlitePath.path) {
            print("📦 Copiando banco pré-populado...")

            guard let sqliteSrc = Bundle.main.url(/service/forresource: "DataBase", withExtension: "sqlite"),
                  let shmSrc = Bundle.main.url(/service/forresource: "DataBase", withExtension: "sqlite-shm"),
                  let walSrc = Bundle.main.url(/service/forresource: "DataBase", withExtension: "sqlite-wal") else {
                print("❌ Arquivos .sqlite não encontrados no bundle.")
                return
            }

            do {
                try fileManager.copyItem(at: sqliteSrc, to: sqlitePath)
                try fileManager.copyItem(at: shmSrc, to: supportURL.appendingPathComponent("DataBase.sqlite-shm"))
                try fileManager.copyItem(at: walSrc, to: supportURL.appendingPathComponent("DataBase.sqlite-wal"))

                print("✅ Banco copiado com sucesso para Application Support.")
            } catch {
                print("❌ Erro ao copiar banco: \(error)")
            }
        } else {
            print("✔️ Banco já existe. Nenhuma cópia necessária.")
        }
    }

    func saveContext() {
        let context = container.viewContext
        if context.hasChanges {
            do {
                try context.save()
                print("✅ Alterações salvas no banco.")
            } catch {
                print("❌ Erro ao salvar contexto: \(error)")
            }
        }
    }
}

Passo 5: Testar

❌ Como meu app de testes já está populado, ao executar o app novamente, a cópia dos arquivos não será realizada. Isso acontece porque o arquivo .sqlite já existe na pasta Application Support.

Irei apagar o App do meu simulador para testar se a cópia está, de fato, funcionando corretamente. Veja que agora deu certo, dado que meu BD está vazio

(Obs: deve ter apenas uma versão do seu app no simulador)

Conclusão

Dessa forma, conseguimos integrar um banco de dados SQLite já populado diretamente no projeto, garantindo persistência e consistência nos dados desde a primeira execução do app — ressalto que é ideal para times que compartilham o projeto iOS via Git ou precisam de dados de teste consistentes durante o desenvolvimento.

Caso esteja enfrentando problemas com a cópia do banco, revise:

• Se os 3 arquivos (.sqlite, .sqlite-shm, .sqlite-wal) estão no bundle; além de estarem marcado no Target.

• Se o nome do NSPersistentContainer coincide com o nome do arquivo;

• Se o banco já existe em Application Support (neste caso, a cópia será ignorada).

⸻

💡 Dica Final

Se quiser testar novamente o carregamento do banco, basta apagar o app do simulador e executar o projeto outra vez. Assim, você valida que os dados realmente estão sendo copiados apenas na primeira inicialização.

Guia: Como Subir um App iOS com Core Data Pré-Populado no GitHub was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.

No challenge da Ilhéu de Nova Descoberta, da Apple Developer Academy UFPE, cada grupo teve que fazer um app que explorasse suas paixões. No trio “Ciao, Italia”, tivemos que criar um app que envolvesse nossas três paixões: idioma (italiano), viagem e arte.

Dessa forma, chegamos a uma Solution Concept:

“Um app que simula uma situação cotidiana e ensina expressões-chaves ao viajar”.

Um dos pontos mais interessantes trabalhados ao longo do desenvolvimento dele foi criar um botão de leitura de um texto predefinido no SwiftUI. Para fazê-lo, usamos de referência este post no Medium para nos ajudar.

Como começar?

import AVFoundation

class SpeechManager {
    private let synthesizer = AVSpeechSynthesizer()
    
    func speak(_ text: String) {
        let utterance = AVSpeechUtterance(string: text)
        utterance.voice = AVSpeechSynthesisVoice(language: "it-IT") // Italiano
        utterance.rate = 0.5
        synthesizer.speak(utterance)
    }
}

Primeiramente, utilizamos o import AVFoundation para termos acesso ao AVSpeechSynthesizer, o que fornecerá uma variedade de controles para o áudio (síntese de fala).

Logo, criamos uma classe chamada SpeechManager com uma propriedade privada chamada synthesizer que inicializa a instância AVSpeechSynthesizer que é o que realizará a síntese de fala.

Depois disso, criamos uma uma função chamada speak que aceita uma string como parâmetro, é ela que vai converter o texto em fala. Nela criamos uma constante chamada utterance que terá a instância de AVSpeechUtterance com o texto que vai ser fornecido para configurar a maneira que a fala será sintetizada (a dicção).

Para configurar o idioma da fala, utilizamos utterance.voice com o AVSpeechSynthesisVoice. Nesse exemplo configuramos “it-IT” para que a linguagem seja italiano.

A utterance.rate é usada para configurar a velocidade da fala, o valor padrão é o 0.5 mas pode variar de 0 a 1.

E por último, chamamos o método speak do synthesizer com a utterance para iniciar a síntese da fala com as configurações que criamos.

E agora, como criar um botão?

import SwiftUI
struct ButtonView: View {
    private let speechManager = SpeechManager()
    
    var body: some View {
        VStack {
            Button(action: {
                speechManager.speak("Ciao, come stai?")
            }) {
                ZStack {
                    Capsule()
                        .foregroundColor(.blue)
                        .frame(width: 140, height: 44)
                    Text("FALAR")
                        .foregroundColor(.white)
                }
            }
        }
    }
}

Para criarmos um botão de leitura de texto, abrimos uma outra view que contém uma instância privada de SpeechManager chamada speechManaager que trará as funcionalidades da síntese de fala que foram definidas na classe SpeechManager.

Depois de estilizar o botão, colocamos em sua ação o método speak do speechManager e passamos uma string, no exemplo colocamos “Ciao, come stai?” para que seja falada ao ser pressionado o botão “FALAR”.

Espero que este tutorial tenha sido útil e que você tenha aprendido a criar um botão de leitura de texto em SwiftUI! Se você tiver alguma dúvida ou sugestão, sinta-se à vontade para deixar um comentário abaixo.

Desenvolvendo um Botão de Leitura de Texto com SwiftUI was originally published in Apple Developer Academy | UFPE on Medium, where people are continuing the conversation by highlighting and responding to this story.