viewWillAppear no iOS: a essência do método e como usá-lo

O que é viewWillAppear

viewWillAppear é um método UIViewController que o UIKit chama imediatamente antes de adicionar a View à hierarquia de janelas. Neste momento, a View já tem suas dimensões finais após as passagens de Auto Layout, mas ainda não está visível para o usuário — a animação de transição ainda não começou ou está em andamento. O desenvolvedor sobrescreve este método para realizar operações que devem ocorrer antes de cada exibição da tela.

Ao contrário de viewDidLoad, que é disparado apenas uma vez, viewWillAppear é chamado toda vez que a tela está prestes a aparecer: durante a abertura inicial, ao retornar de um controlador filho, após fechar uma janela modal e ao alternar abas do TabBar. Isso o torna um método chave para manter um estado de interface atualizado.

O método aceita um parâmetro animated do tipo Bool, que é true se o aparecimento da tela for acompanhado de animação. Este parâmetro é conveniente para passar para métodos NavigationBar e TabBar, que também têm um parâmetro similar para comportamento consistente.

Quando viewWillAppear é chamado

O momento da chamada viewWillAppear depende do tipo de navegação, mas a regra geral permanece a mesma: o método é disparado antes que a View se torne visível. Vamos considerar os cenários principais.

Na primeira abertura da tela

Após viewDidLoad, o UIKit começa a preparação para exibição: a View é adicionada à hierarquia, as passagens de layout são acionadas, e imediatamente antes do início da animação de transição, viewWillAppear é chamado. Neste momento, a tela ainda não está visível, mas todas as subviews têm tamanhos corretos e seu conteúdo pode ser atualizado com segurança.

Ao retornar do NavigationController

Quando o usuário toca no botão voltar ou chama programaticamente popViewController, o UIKit retorna à tela anterior e chama seu viewWillAppear. Este é o cenário principal para usar viewWillAppear — atualizar uma lista após adicionar um item ou sincronizar configurações.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    updateBadgeCount()
}

Ao fechar uma janela modal

Após fechar um controlador apresentado modalmente, o UIKit chama viewWillAppear no controlador que o apresentou. Este cenário requer atenção especial se você usar delegados ou closures para passar dados de volta — viewWillAppear garante que a tela atualize após receber o resultado.

Ao alternar abas do TabBar

O TabBarController chama viewWillAppear no controlador da aba selecionada toda vez que ocorre uma alternância. Se a aba exibe dados dinâmicos — taxas de câmbio, notificações, status do usuário — viewWillAppear é o local ideal para atualizá-los.

Tarefas práticas em viewWillAppear

viewWillAppear resolve várias tarefas específicas que são impossíveis ou subótimas de realizar em outros métodos. Vamos ver as principais.

Atualizar dados de tabela

O uso mais comum de viewWillAppear é recarregar uma UITableView ou UICollectionView toda vez que a tela aparece. Se os dados podem ter mudado na tela anterior (item adicionado, status alterado), chamar reloadData em viewWillAppear garante que o usuário veja informações atualizadas.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    viewModel.synchronize()
    tableView.reloadData()
}

Configurar NavigationBar e TabBar

Em viewWillAppear é conveniente configurar a aparência da NavigationBar: ocultá-la ou exibi-la, mudar sua cor, definir um título grande. Se diferentes telas têm estilos diferentes de NavigationBar, viewWillAppear é o lugar certo para essas mudanças, já que viewDidLoad é chamado apenas uma vez.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    navigationController?.setNavigationBarHidden(
        false, animated: animated
    )
    navigationController?.navigationBar.prefersLargeTitles = true
    tabBarController?.tabBar.isHidden = false
}

Assinar notificações temporárias

Notificações que só fazem sentido quando a tela está visível — notificações de teclado, notificações de mudança de conteúdo — são assinadas em viewWillAppear e canceladas em viewDidDisappear. Isso evita manipuladores desnecessários quando a tela não está ativa e protege contra vazamentos de memória.

Restaurar estado da interface

Se a tela pode ser ocultada pelo aplicativo ou minimizada, viewWillAppear é um local conveniente para restaurar o estado da interface: alternar segmentos, restaurar posição de rolagem, redefinir alterações temporárias. O usuário obtém a tela em um estado previsível cada vez que ela aparece.

Atualizar badges e contadores

Em telas que exibem contadores de mensagens não lidas, avaliações ou notificações, viewWillAppear é o lugar adequado para atualizá-los. Se o usuário pode ter alterado a quantidade em outra tela, aqui são chamados o recálculo e a atualização de UITabBarItem.badgeValue ou indicadores personalizados. Isso garante que o usuário sempre veja números atualizados, independentemente de quanto tempo ficou em outras telas.

Atenção especial deve ser dada ao trabalhar com collectionView: se os dados na tela são apresentados como uma grade com células contendo contadores ou status, sua atualização em viewWillAppear deve ser seletiva. Em vez de um reloadData completo, use reloadItemsAtIndexPaths para células visíveis, para evitar cintilação e perda da posição de rolagem.

Diferenças entre viewWillAppear e viewDidLoad

Entender a diferença entre viewWillAppear e viewDidLoad é a base de uma arquitetura correta de UIViewController. Esses métodos têm frequência de chamada diferente, contexto diferente e propósito diferente.

viewDidLoad é chamado uma vez e é adequado para configurações que não mudam com o tempo: registrar células, definir delegados, inicializar constantes. viewWillAppear é chamado em cada aparição e é adequado para operações que precisam ser repetidas: atualizar dados, configurar elementos visíveis, sincronizar estado.

A regra de ouro: se uma operação deve ser executada apenas uma vez — coloque-a em viewDidLoad. Se deve ser executada toda vez que você retorna à tela — coloque-a em viewWillAppear.

Erros comuns em viewWillAppear

O uso incorreto de viewWillAppear pode levar a problemas de desempenho, atualizações excessivas e estado inconsistente da interface. Vamos ver os erros mais comuns.

O primeiro erro — duplicar a lógica de viewDidLoad. Se você registra células de tabela tanto em viewDidLoad quanto em viewWillAppear, o registro será executado várias vezes, embora uma configuração única seja suficiente. Mova todas as configurações únicas para viewDidLoad.

O segundo erro — reloadData incondicional em cada aparição. Se os dados não mudaram, recarregar a tabela causa consultas desnecessárias ao data source e redesenho de células, reduzindo o desempenho. Verifique se o estado realmente mudou antes de chamar reloadData.

O terceiro erro — trabalhar com requisições de rede sem considerar que a tela pode ser ocultada novamente antes da requisição ser concluída. Se você inicia uma requisição URLSession em viewWillAppear e o usuário imediatamente navega para outra tela, o resultado pode ser aplicado a uma View já oculta. Use tarefas canceláveis ou verifique isViewLoaded e window antes de atualizar.

O quarto erro — esquecer de chamar super. Não chamar super.viewWillAppear pode quebrar o comportamento dos controladores pai (UINavigationController, UITabBarController) e levar a um tratamento incorreto de gestos e transições. super deve sempre ser chamado.

O quinto erro — modificar constraints sem chamar layoutIfNeeded. Se você altera constraints programaticamente em viewWillAppear, o UIKit não as aplica imediatamente — as alterações se acumulam até a próxima passagem de layout. Para aplicação imediata das alterações após modificar constraints, chame view.layoutIfNeeded(). Isso é especialmente importante ao ajustar a altura de elementos dependentes de conteúdo.

O sexto erro — tentar executar animação em viewWillAppear. Como mencionado acima, o UIKit ainda está processando a animação de transição, e sua animação pode competir com a do sistema. Se você precisa que um elemento apareça com um efeito, use animação de entrada em viewDidAppear, e em viewWillAppear apenas configure o estado inicial: transparência 0, transform em escala 0.8, e assim por diante.

O sétimo erro — ignorar o parâmetro animated. Alguns desenvolvedores não verificam o valor de animated em viewWillAppear e executam operações que deveriam depender da presença de animação. Por exemplo, ocultar a NavigationBar quando animated = false pode ser feito sem animação, e quando animated = true — com animação, para que a transição pareça suave. Sempre passe o parâmetro animated para os métodos UIKit apropriados.

O oitavo erro — modificar a interface quando a tela não está visível. Se você inicia uma requisição de rede em viewWillAppear e seu bloco de completion atualiza a interface quando a tela já pode ter desaparecido, o usuário verá cintilação ou estado inconsistente. Sempre verifique isViewLoaded e window antes de atualizar a interface em closures. Esta simples ação previne crashes e redesenho desnecessário da interface.