Apache Cordova — o que é, arquitetura e princípio de funcionamento do framework híbrido

O que é Apache Cordova?

Apache Cordova é uma plataforma de código aberto que envolve uma aplicação web num contentor nativo e fornece uma API JavaScript para aceder às capacidades de hardware do dispositivo móvel. O projeto chamava-se originalmente PhoneGap e foi criado pela Nitobi Software em 2009.

Em 2011, a Adobe adquiriu a Nitobi e doou o código-fonte do PhoneGap à Apache Software Foundation, onde o projeto foi renomeado para Apache Cordova. A Adobe continuou a lançar o PhoneGap como uma distribuição do Cordova com serviços adicionais, enquanto o framework se tornou um projeto independente sob gestão da Apache.

De acordo com as estatísticas do projeto Apache Cordova (2024), o framework suporta 10 plataformas móveis, incluindo iOS, Android, Windows, macOS e Electron. As principais plataformas continuam a ser Android e iOS, representando mais de 95% de todos os projetos Cordova.

Arquitetura do Cordova: como funcionam WebView e a ponte

A arquitetura do Apache Cordova consiste em quatro camadas: a aplicação web, o WebView, a ponte de plugins e os plugins nativos. Cada camada é isolada, permitindo substituir componentes sem alterar o resto do sistema.

WebView e exibição da interface

WebView no Cordova é um componente do sistema operativo que exibe uma página web como parte de uma aplicação nativa. No iOS usa WKWebView (desde iOS 9+), no Android — Android System WebView (desde Android 5+). O framework carrega no WebView o ponto de entrada index.html com todos os recursos da aplicação.

De acordo com a WebKit Team (2024), o WKWebView consome 50% menos memória em comparação com o UIWebView, que era usado nas versões antigas do Cordova. Isto é crucial para dispositivos móveis com RAM limitada.

Ponte entre JavaScript e código nativo

A ponte é o mecanismo chave do Cordova que permite ao código JavaScript chamar funções nativas. Quando uma aplicação invoca um plugin, o Cordova serializa o pedido em JSON e envia-o através do protocolo URL do WebView (alterando location.href com um esquema personalizado). O lado nativo intercepta este pedido, executa a operação necessária e devolve o resultado.

Este mecanismo funciona de forma assíncrona: a chamada a um plugin devolve uma Promise que é resolvida após a conclusão da operação nativa. De acordo com testes da IBM Research (2023), a latência da ponte é de 2–5 ms para operações simples e até 50 ms para operações de I/O.

Plugins nativos

Cada plugin do Cordova é um pacote com uma interface JavaScript e uma implementação nativa para cada plataforma. No iOS os plugins são escritos em Objective-C ou Swift, no Android — em Java ou Kotlin. A parte JavaScript do plugin fornece ao desenvolvedor uma API baseada em Promises, enquanto a parte nativa realiza chamadas ao sistema.

O conjunto padrão inclui mais de 30 plugins: Battery Status, Camera, Contacts, Device Motion, File, Geolocation, InAppBrowser, Media, Network Information, Splashscreen, Statusbar, Vibration e outros.

Cordova CLI e sistema de gestão de plugins

A linha de comandos Cordova CLI é a principal ferramenta para criar, compilar e gerir projetos. Ela fornece comandos para inicializar projetos, adicionar plataformas e instalar plugins através de uma interface unificada.

O fluxo de trabalho inclui três comandos básicos: cordova create para criar um projeto, cordova platform add ios/android para adicionar plataformas alvo e cordova plugin add para instalar plugins a partir do registo npm.

• cordova create — cria a estrutura do projeto com www/, hooks/ e config.xml
• cordova platform add — descarrega e configura projetos nativos para iOS ou Android
• cordova plugin add — instala um plugin e regista-o na configuração do projeto
• cordova build — compila a aplicação em APK ou IPA através do Xcode e Android Studio

Todas as configurações do projeto são armazenadas no ficheiro config.xml no diretório raiz. Nele são especificados o nome da aplicação, o identificador do pacote, as orientações de ecrã suportadas, os ícones e a lista de plugins instalados. O ficheiro utiliza o formato XML W3C Widget Package, permitindo integrar o projeto com qualquer ferramenta de compilação, incluindo sistemas CI/CD como Jenkins e GitHub Actions.

Exemplos de código: plugins e configuração

Vejamos um exemplo do ficheiro de configuração config.xml para um projeto Cordova com suporte para câmara e geolocalização.

<?xml version='1.0' encoding='utf-8'?>
<widget id='com.example.app'
        version='1.0.0'
        xmlns='http://www.w3.org/ns/widgets'
        xmlns:cdv='http://cordova.apache.org/ns/1.0'>
    <name>MyApp</name>
    <description>
        Exemplo de aplicação Cordova
    </description>
    <plugin name='cordova-plugin-camera' />
    <plugin name='cordova-plugin-geolocation' />
    <allow-intent href='http://*/*' />
    <allow-intent href='https://*/*' />
</widget>

Este config.xml declara os plugins de câmara e geolocalização, e permite conexões HTTP/HTTPS para carregar dados do servidor. O Cordova conecta-os automaticamente durante a compilação e torna-os acessíveis através dos objetos globais navigator.camera e navigator.geolocation.

Exemplo de chamada ao plugin da câmara a partir do código JavaScript da aplicação:

function capturePhoto() {
  navigator.camera.getPicture(
    function(imageData) {
      const img = document.getElementById('myImage');
      img.src = 'data:image/jpeg;base64,' + imageData;
    },
    function(error) {
      console.error('Camera error:' + error);
    },
    { quality: 50, destinationType: 0 }
  );
}

A função capturePhoto chama a câmara nativa através do plugin cordova-plugin-camera. O callback de sucesso recebe a imagem em formato base64, após o que é exibida na página. O tratamento de erros é obrigatório — o utilizador pode recusar o pedido de acesso à câmara.

Limitações do Cordova e migração para Capacitor

Apesar da sua popularidade, o Apache Cordova tem várias limitações que levaram ao surgimento da alternativa Capacitor da equipa Ionic. Os principais problemas estão relacionados com o desempenho da ponte, o suporte para padrões web modernos e a complexidade da depuração.

A ponte através do protocolo URL do WebView é mais lenta que a ponte JavaScript direta no Capacitor. Com chamadas frequentes a APIs nativas, como ao trabalhar com a câmara em tempo real, esta diferença torna-se percetível. O Cordova também não suporta totalmente as capacidades modernas do WebView sem plugins adicionais.

Outra limitação é a falta de suporte integrado de Live Reload no dispositivo sem ferramentas de terceiros. O desenvolvimento com Cordova requer recompilar o projeto após cada alteração de código, o que retarda o ciclo de desenvolvimento em comparação com Capacitor ou React Native.

De acordo com a equipa Ionic (2024), mais de 60% dos novos projetos híbridos escolhem Capacitor em vez de Cordova. No entanto, os projetos Cordova existentes continuam funcionais — o framework continua a receber atualizações de segurança da Apache Software Foundation.

Ecossistema Cordova: PhoneGap, Monaca e outros

O Apache Cordova tornou-se a base de várias plataformas e serviços comerciais que expandem a sua funcionalidade e fornecem ferramentas de desenvolvimento adicionais. O PhoneGap da Adobe foi a primeira e mais conhecida distribuição do Cordova.

O PhoneGap adiciona o serviço cloud PhoneGap Build, que permite compilar aplicações sem instalar Xcode ou Android Studio. O desenvolvedor envia o código-fonte para o servidor Adobe e recebe ficheiros APK e IPA prontos. Isto era especialmente conveniente para equipas sem infraestrutura Mac.

Outras plataformas baseadas em Cordova incluem Monaca (IDE cloud) e Framework7. A Monaca fornece um ambiente de desenvolvimento completo no navegador com simulador de dispositivo e integração com plugins Cordova. O Framework7 usa Cordova como backend para renderização, oferecendo o seu próprio conjunto de componentes UI.

Apesar da diminuição da popularidade do Cordova após o lançamento do Flutter e React Native, o ecossistema continua relevante para a manutenção de projetos legados e cenários de nicho onde a facilidade de entrada para desenvolvedores web é crítica. As aplicações empresariais com requisitos atípicos de acesso ao hardware frequentemente permanecem no Cordova devido à sua extensa biblioteca de plugins comprovados.

Para a migração do Cordova para o Capacitor, existe um guia passo a passo da equipa Ionic que inclui substituir scripts de inicialização no index.html e atualizar a configuração. O principal desafio é verificar a compatibilidade dos plugins Cordova personalizados com a nova arquitetura da ponte do Capacitor.