Desenvolvimento Série 60 para quem desenvolve em Linux - parte 3

"Quer moleza, vai mastigar água de cabeça pra baixo!" -- Desenvolvedor Symbian respondendo à dúvida de um novato.

OpenC -- a luz no fim do túnel

O principal sintoma de que a API do Symbian é mais complicada do que seria razoável, é a baixa dinâmica da comunidade de desenvolvedores. É difícil encontrar software livre para Symbian, e é difícil encontrar respostas para dúvidas no Google. Isso para um sistema operacional que roda em 118 milhões de dispositivos.

Enxerga-se melhor o problema comparando com a comunidade Palm OS. O Palm é uma plataforma moribunda, muita gente diz que o conceito de PDA é obsoleto, mas apesar de tudo isso há uma comunidade muito atuante. Isso se conseguiu com decisões corretas lá no início do Palm: uma API com complexidade dentro do razoável, "parecida" com o que já existia (comunicação via sockets, por exemplo, é exatamente igual ao POSIX), e ferramentas de boa qualidade. O emulador do Palm já era bom desde a época que ele usava processador 68000. E sempre teve emulador e compilador Palm para Linux. De graça.

Enfim, parece que pelo menos a plataforma Série 60 enxergou o óbvio ululante, e lançou o OpenC - uma biblioteca que implementa a API POSIX, threads inclusive, mais o porte de algumas bibliotecas que são "padrão de fato" no mundo do software livre: libz, OpenSSL e GLib/GObject.

O OpenC é para Série 60, não para Symbian. Isso exclui dispositivos Série 80, Série 90 e UIQ. Mas como a Série 60 é a variante mais forte comercialmente, beneficia a maior fatia de usuários.

Posso dizer por experiência própria que o OpenC é um bom software. Tem demonstrado estabilidade e tenta oferecer o máximo possível de recursos do POSIX. Desta forma, o porte de uma aplicação ou biblioteca para OpenC é basicamente tranqüila. Tenho inclusive usando muitas threads, que em Symbian normal é considerado "heresia".

Alguns "issues" a serem considerados, ao menos os que me afetaram:

* O suporte a sockets do OpenC tem algumas peculiaridades. Não é possível obter a lista de interfaces da máquina, porque celular não tem interface de rede, tem "access point", que só é ativado na hora que realmente precisa, para economizar energia. O OpenC oferece chamadas ioctl() adicionais (fora do padrão POSIX) para lidar com access points.

* Ainda na parte de rede, há algumas diferenças na API. É preciso fazer bind() em todo soquete, seja conexão TCP ou UDP, do contrário não funciona. É na hora do bind() que aparece a janelinha perguntando que access point você quer usar (salvo você ter selecionado via ioctl() antes dentro do aplicativo).

* Ao criar um soquete UDP, é necessário passar socket(..., IPPROTO_UDP) no terceiro parâmetro. Se passar zero, não funciona (o comportamento POSIX correto é usar UDP como default). No caso de soquete TCP, o OpenC usa corretamente TCP como default, não é necessário passar IPPROTO_TCP.

* A versão atual do OpenC, que é um add-on para 3rd Edition FP1, não suporta multicast. O programa compila mas vai retornar erro no setsockopt(IP_ADD_MEMBERSHIP). O SDK 3rd Edition Feature Pack 2 beta já tem OpenC embutido e suporta multicast, mas não há nenhum celular com FP2 na praça ainda.

* Quando o select() retorna dizendo que há arquivos ou soquetes a serem lidos/gravados, o programa *tem* de tratar todos nessa oportunidade. Se o programa "esquecer" algum soquete, o próximo select() NÃO vai retornar indicando que aquele soquete ainda precisa ser tratado. Muito código POSIX por aí trata apenas um soquete de cada vez a cada retorno do select(); essa estratégia falhará no OpenC, então é bom ficar esperto.

* Não há como implementar sinais POSIX em Symbian, portanto o OpenC não oferece esta funcionalidade. Aplicativos que dependem de sinais para funcionar são os mais trabalhosos para portar. Em particular quando usam sinais para comunicação entre uma thread e outra. Também não há como criar subprocessos via fork().

* O OpenC não oferece nada em termos de interface gráfica, ainda. É possível fazer um aplicativo OpenC completamente livre da API Symbian, com ponto de entrada main() e tudo, mas ele não vai ter rosto. Para um aplicativo "normal", a solução é usar API Symbian para interface de usuário (naquele esquema cheio de classes do post anterior), e usar OpenC apenas na lógica.

Imagina-se que OpenC vá oferecer UI no futuro. Considerando que o OpenC já possui o GLib portado, que o Maemo é baseado no GTK+, e que o GTK+ é o "padrão de fato" no mundo do software livre, as apostas são que o OpenC ofereça GTK+ um dia. Tomara :)

* Não só UI, mas muita outra coisa cai fora da API OpenC. Para usar multimídia, câmera, GPS, discar um número, etc. você ainda terá de usar a API Symbian. Em comparação, o Python para Série 60 dá acesso a todos estes recursos.

Pior: o Python para Série 60 é assinado pela Nokia, e tem capabilities bastante extensas. Já um aplicativo OpenC tem de ser assinado por você, e isso implica em ter capabilities restritas, ou então ter de cair com o cobre para homologar seu aplicativo no Symbian Signed.

(Imagino que, um dia, o OpenC vá dar acesso a estes recursos de forma "organizada", não dando acesso a /dev/dsp, mas sim usando os padrões do freedesktop.org tal qual o Maemo. No caso de áudio, vídeo ou fotos, a API padrão de fato seria o GStreamer. Mas não tenho a menor idéia se é possível portar o GStreamer para Symbian.)

* A saída padrão (STDIO) ocorre dentro de um aplicativo separado (STDIO server), e não num console separado. Tem a vantagem de funcionar mesmo no celular (para o usuário final não ver as mensagens, basta remover o STDIO server do celular). E a desvantagem da tela ter pequeno tamanho, portanto é incômodo usá-lo para depuração (seria melhor poder jogar a saída num terminal do PC).

E finalmente, sempre temos de lembrar que o desenvolvimento em OpenC acontece dentro do contexto das ferramentas Symbian, o que implica em Windows e um emulador problemático. Assim, embora o OpenC seja vendido como um convite à comunidade de software livre a experimentar o Symbian, eu acho exatamente o contrário: o OpenC veio é para facilitar a vida dos desenvolvedores Symbian!

Resumindo, reconheço que há interesse da Nokia em construir a ponte Symbian-software livre. E aprecio a iniciativa. Mas, diferente do anunciado, eles começaram a construir a ponte pelo lado "de lá" do rio.