#020 – Uma Viagem na Evolução do Desenvolvimento Móvel

Embarque com a equipe do podcast nessa jornada desde os primórdios do desenvolvimento de aplicações móveis para os dispositivos da Palm, passando pelos celulares que rodavam J2ME até as modernas soluções para os smartphones Android e iOS.

Nosso guia é o Telmo Pimentel Mota, desenvolvedor móvel desde o início do século, com projetos executados para Nokia, Motorola e Samsung. O Telmo é Cientista da Computação pela Universidade Federal da Paraíba e trabalha no C.E.S.A.R em Recife desde 2003.

Se você gostou compartilhe com seus amigos nas redes sociais e deixe o seu comentário aqui no site, no nosso Twitter @podebug, na nossa página do Facebook ou mande um e-mail para [email protected]

Para baixar: Arquivo MP3

Assine o Podcast

Links do Episódio

Wikipedia: Graffiti (Palm OS)
App Android: Graffiti Pro
Wikipedia: Nokia device N-Gage
Artigo: Review do Motorola iDEN i886 (creekside)
Wikipedia: Aplicativo “I am Rich”
Dica do Marcelo: Pilotando! (podcast)
Dicas do Vladimir:
- Code Complete (livro)
- Clean Code (livro)
Dica do Borba: The Paypal Wars (livro)
Dica do Telmo: Communities Dominate Brands (blog)

Créditos

Música tema e audio clips por Jason Shaw do site audionautix.com
Música de encerramento do site audioblocks.com
Edição e mixagem por Marcelo Lv Cabral

6 Responses to "#020 – Uma Viagem na Evolução do Desenvolvimento Móvel"

Manoel Neto disse:

25/03/2016 às 16:49

Parabéns pelo podcast e ao convidado Telmo Pimentel pela viagem através de uma história que cada vez parece se tornar mais curta, tamanha a evolução!

Responder
Mackenzie Melo disse:

31/03/2016 às 20:41

E então pessoal. Primeira vez comentando aqui, apesar de falar com Mr. Cabral de quando em vez… 🙂

Senti uma certa saudade do meu Palm 5. Lembro-me com certa frustração quando o dono dele apareceu e o levou embora. E o pior que nem sei de onde ele tirou. Só sei que quando me dei conta, já tinha desaparecido… 🙂 Tive também um Palm Pilot – acho que era um com o símbolo da US Robotics no canto superior direito – mas não tenho muita certeza. Já faz tanto tempo… 😀

Queria só deixar uma sensação de incompletude neste episódio. Por que o Windows Mobile foi deixado de fora? Não riam muito da minha pergunta, por favor… 😀 Pergunto mesmo assim pois sei que hoje ainda tem muitos devices que o utilizam – além de, é claro, o Windows Phone. Por exemplo, os scanners que a turma da Fedex – pelo menos aqui nos EUA – rodam com Windows Mobile.

Abração e obrigado pelo Podcast. Muito Massa!

Responder
Fred Monteiro disse:

20/04/2016 às 02:06

Opa pessoal!

Muito massa o podcast de vocês, os temas são bem relevantes e abordados de uma forma bem interessante. Estou escutando em ordem e de forma atrasada, por isso demoro nos meus comentários.

Queria acrescentar alguns detalhes a mais em relação ao PalmOS, já que tive a oportunidade de trabalhar com ele por aproximadamente 18 meses (na Mobile, que foi mencionada pelo Telmo nesse episódio).

A plataforma que ele descreveu me pareceu ser o Satellite Forms (SF). SF era um ambiente de desenvolvimento rápido para o PalmOS que era desenvolvido por uma empresa que também tinha outros produtos relacionados, se não me falha a memória, incluindo a parte de servidor de sincronização. Ter um nível bem alto (quase um Delphi), porém, era a única virtude do SF. De resto, o desenvolvimento nessa plataforma era deficiente em vários aspectos, incluindo performance e paridade com o OS. Quando entrei na Mobile eles estavam colocando o SF em segundo plano para investir em desenvolvimento diretamente em cima das APIs do OS, usando um ambiente de desenvolvimento em C chamado Code Warrior (CW). No CW estávamos direto em cima do OS, então tínhamos acesso a todas as APIs, além do desempenho ser muito superior.

O fato de ter acesso às APIs do OS diretamente possibilitou que as aplicações escritas no CW pudessem ser atualizadas over-the-air. O nosso maior cliente na época tinha 1100 Palms rodando nossa app de automação de força de vendas. Tanto as cargas de dados (atualização total semanal do livro de preços e atualizações diárias incrementais) quanto atualizações do próprio sistema eram feitas via modem. Por comodidade, separamos a aplicações em 2: uma principal e uma que era o atualizador. A idéia é que o atualizador fosse instalado permanentemente na flash dos Palms (havia uma app chamada After Burner que fazia isso), para evitar que os usuários tivessem que conectar ao computador, caso perdessem a app. O atualizador era pequeno, coisa de 4Kb (que seria um bom tamanho para incluir na flash). Já a app era maior, beirando os 300Kb (que a gente transferia usando compressão, dado que os modems eram de 9600bps).

De uma forma geral, o desenvolvimento para PalmOS, mesmo em SF, era uma experiência muito satisfatória por conta da qualidade e variedade das ferramentas existentes (tanto disponibilizadas pela Palm quanto por terceiros). Muito embora a parte do sincronizador padrão deixasse um pouco a desejar do ponto de vista do desenvolvedor (se não me falha a memória, a Palm licenciava o seu próprio servidor e a licença era bem cara), não existiam obstáculos para quem quisesse ter sua própria implementação (especialmente quando eles adicionaram o suporte a TCP/IP.

Ao contrário da Microsoft, que estava no mercado com o PocketPC visando os computadores móveis (se não me falha a memória, lançado originalmente para o HP LX100), de onde se originou o Windows Mobile, a Palm desenvolveu o seu OS a partir do zero. Então toda a arquitetura do sistema existia para servir um produto que não tinha as mesmas características de um PC. Por um lado, limitações de memória, CPU, tela e bateria, além de conectividade eventual e de banda limitada. Por outro lado, características não presentes no PC, como a própria mobilizade em si e uma tela sensível ao toque. O PalmOS foi, sem a menor sombra de dúvida, a melhor plataforma móvel com a qual eu já trabalhei, especialmente por isso: era uma plataforma. Você aprendia sobre o modelo de desenvolvimento até mesmo nos tutoriais da própria Palm. Lembro como se fosse hoje: no primeiro capítulo dos manuais oficiais eles delineavam a visão de computação móvel. A aplicação tinha que rodar rápido e ser responsiva. Alternar entre aplicações tem que ser uma tarefa instantânea. As funcionalidades devem seguir a regra dos 80/20 (20% delas são usadas 80% do tempo).

O sistema era monolítico. Cada aplicação nada mais era que uma DLL que implementava uma interface conhecida, com um entry-point que era a chamada principal da sua aplicação. Nesse entry-point, você recebia um bloco de memória que vinha com parâmetros de invocação da sua aplicação e mais um código de evento. Esse código é o que determinava qual seria o comportamento esperado. Não lembro em detalhes, mas eram coisa de 8 a 12 diferentes, e dependendo do código, existiam certas expectativas que a aplicação tinha que cumprir. Abrir a aplicação em modo full era um deles, nesse caso você tinha acesso a abrir a UI. Mas havia outros códigos, como incluir, alterar ou remover registros, fazer uma busca, etc, que não dava à aplicação acesso à UI.

A memória era um capítulo à parte. Primeiro, no PalmOS não existia uma storage física. Tudo era RAM dinâmica, ligada na bateria. Se você deixasse o Palm sem pilha por muito tempo, perdia tudo o que estava armazenado. Por outro lado, era super rápido. Se comparado com outros dispositivos que usavam memória flash, a DRAM era absurdamente mais rápida. Tanto que um Palm com processador (Dragon?) rodando a 16MHz tinha um desempenho comparável a um PocketPC rodando a 60, 100MHz. Como eu falei, a memória era uma só. O sistema operacional é quem dividia ela em 2 partes: heap e storage. A heap era disponível para as aplicações usarem diretamente (ou seja, nela você podia rodar um malloc), a storage tinha uma arquitetura diferente e era exposta pelo OS com uma API própria. Num dispositivo com memória pequena, os riscos de fragmentação da memória são mais altos. Então em vez de dar acesso a ponteiros fixos na memória, o que o PalmOS fazia é que ele usava uma indireção dupla. O OS mantinha uma tabela de ponteiros para blocos livres e ocupados. Quando você queria alocar um novo bloco de memória, o OS marcava nessa tabela, mas não lhe devolvia o bloco. Devolvia o handle (o índice da tabela). De posse do handle, você podia fazer uma outra chamada que era travar o handle. Aí sim, você podia escrever na memória. Depois você tinha que destravar o handle. Uma vez destravado, todos os ponteiros que você mantinha para dentro do block se tornam potencialmente inválidos. Isso porque quando a memória ficava fragmentada além de um certo ponto, o OS fazia uma compactação. Nesse ponto, todos os endereços podiam potencialmente mudar. Mas o seu handle continuava válido. O lock seguinte lhe devolvia o endereço físico da nova localização do bloco. Apesar de parecer complicado, era uma solução elegante e código bem-feito funcionava sem problemas.

Em relação à heap, ela era determinada por 2 fatores: a versão do sistema operacional e a quantidade de memória física. Não lembro detalhadamente da tabela, mas, grosso modo, no PalmOS 3.algumacoisa, a heap era de 48Kb se o seu device tivesse 4MB de memória. Creio que era 36Kb para devices de 2MB. Na versão 3.5 (acho) a heap pulou para 96KB nos devices com 4MB.

No quesito ferramentas, o emulador do PalmOS era fantástico. Não só emulava o hardware perfeitamente (você colocava a ROM no emulador para ele funcionar), como dava acesso a várias funcionalidades além do OS. Você podia capturar um profiling da aplicação rodando e ele indicava cada chamada, quanto de memória alocou, quantos ciclos de clock (!). O próprio emulador fazia verificações de memory leak, ou de buffer overrun. E ele tanto rodava em tempo real, quanto podia ser acelerado ou retardado em relação ao dispositivo real. No meu dia-a-dia, eu posso dizer que só precisava jogar a aplicação no dispositivo real para fazer um teste de aceitação. O restante do trabalho era todo feito no emulador.

A única experiência negativa que eu tive no Palm foi com desenvolvimento em C++, que nesse caso era um misto de problemas da plataforma de hardware (limitação do processador mesmo) e do ambiente de desenvolvimento (CW). Sem querer entrar em muitos detalhes, mas basicamente existia uma limitação no número de exceções que o seu código em C++ podia jogar, assim como limitação nas vtables. Isso porque o processador era limitado a alocar 64Kb de memória por segmento e o segmentos usados pela pilha de exceções e as vtables facilmente atingiam esses limites numa aplicação comercial.

Para finalizar, e dar uma arrematada de mais alto nível no que era desenvolver para PalmOS, a Mobile entregou talvez meia dúzia de apps escritas em SF, mais umas 3 em CW (embora nem todas tenham sido implantadas). Conseguimos entregar apenas 1 aplicação em PocketPC, que não foi implantada por conta de vários bugs no OS. Embora os iPaqs tivessem 32MB de storage, contra os 4MB em média dos Palms, o storage do iPaq não conseguia armazenar os 15 mil registros necessários para a aplicação (usando SQL Server para PocketPC). O Palm conseguia colocar 5 mil registros em 3MB de storage, e ainda ficava com quase 1MB sobrando.

Responder
Josimar Camargo disse:

27/05/2016 às 06:50

Muito bom o podcast, continue sempre assim, sucesso.

Responder
1. Luiz Borba disse:
  
  09/08/2016 às 18:05
  
  Obrigado Josimar. Vamos continuar sempre dando o nosso melhor…
  
  Responder
Telmo Pimentel Mota disse:

12/03/2019 às 16:22

Taí uma coisa que citei no episódio e ainda está disponível para download, Trash Bin Hero ^_^

http://www.tizenstore.com/main/getDetail.as?Id=WoeXW5F3zp

Responder

Deixe um comentário Cancelar resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.