Semana passada, a Mobits participou do evento Movilforum Latinoamerica 2010, evento promovido pela Vivo e Telefonica para discutir sobre soluções em mobilidade para empresas. Contando com participação de empresários da América Latina, Estados Unidos e Espanha, o evento teve palestras, apresentação de cases e vários stands.

Entre as palestras das fabricantes de celular, as mais interessantes foram da Blackberry, Nokia e Microsoft. A primeira apresentou sua loja de aplicativos (mais uma, pra variar). De acordo com a empresa, os pontos fortes de sua plataforma de desenvolvimento são as APIs para pulicação de propagandas, geo-localização por célula das antenas e a possibilidade de utilizar OpenGL para desenvolvimento de jogos.

Já a Nokia, alvo das minhas dúvidas no meu último post, falou de sua loja de aplicativos, a Ovi Store. E anunciou que o N900 chegará ao Brasil ainda em 2010. Quanto à minha dúvida, sobre o porquê do MeeGo, fui explicado por um engenheiro muito simpático que se tratam de duas coisas diferentes, e que na verdade a real jogada estratégica foi a aquisição da Trolltech, o que permitiu à Nokia juntar todos os desenvolvedores em uma só linguagem de desenvolvimento: a ideia é desenvolver em QT e poder rodar o aplicativo em celulares com Symbian, Maemo e MeeGo. Já o MeeGo vem para fazer com que a Nokia esteja presente também em netbooks e tablets. Ah, bem.

Já com a Microsoft não obtivemos tantas respostas assim. Depois da palestra deles, onde muito pouco foi falado sobre o Windows Phone 7 (na verdade, foi mostrado um vídeo e falado de modo bem geral como ele vai funcionar), perguntamos sobre a incompatibilidade dos aplicativos existentes com essa nova versão do sistema operacional. A resposta, bem vaga, confirmava que não será mesmo possível rodar aplicativos da versão 6 na versão 7. E que as duas versões terão que conviver no mercado ainda por um bom tempo. Ah, mal.

Entre os cases, o mais interessante foi do Consórcio RMTC de Goiânia, que gerencia as frotas de ônibus da região metropolitana de Goiás. Eles criaram um sistema de monitoramento dos ônibus através de aparelhos com GPS, de forma que o motorista tem a informação do trajeto, os pontos onde ele deve parar, se ele está adiantado ou atrasado. Outra coisa bem bacana é o serviço de SMS que eles disponibilizaram para os usuários: você pode receber via SMS informação de quando o ônibus que você deseja irá passar no ponto que você está. E pode saber também qual são os ônibus que passam em um determinado ponto. Muito legal.

Enfim, o evento foi bem proveitoso. Foi bom ver que o mundo não é só iPhone: o aparelho que eu mais vi lá foi o Blackberry, que aliás tinha o melhor stand do evento. Que aconteçam mais desses eventos aqui pras bandas do nosso país, é bom discutir e ficar antenado sobre as novidades na área de mobilidade.

Grande abraço.

Leia também

• Nokia e Intel se unem para criar o MeeGo
• Vivo no mercado de venda de aplicativos
• O que os desenvolvedores devem esperar do novo Windows Phone 7

Buscamos estagiário interessado em design com foco em aplicativos móveis. Saiba mais!

Buscamos alunos cursando a partir do 4º período nos cursos de desenho industrial ou design. Abaixo mais detalhes:

• Vaga: Designer de Interfaces para aplicativos móveis e web sites
• Local: Rio de Janeiro - Centro
• Requisitos: Conhecimentos de informática, ferramentas de design Adobe, HTML/CSS, bom desenhista
• Atividades: Criação de interfaces para aplicativos mobile (iPhone, Android), games, logotipos, páginas web, material promocional (cartões, folders), etc
• Horário: Flexível, 20 horas por semana

Interessados, favor enviar currículo para rh@mobits.com.br até o dia 10 de abril.

Para aqueles que não foram avisados, mês passado Nokia e Intel anunciaram que estão juntando esforços para criar um novo sistema operacional (SO) para smartphones, chamado MeeGo. A ideia é fundir os dois sistemas operacionais que as duas possuem: o Maemo, da Nokia, que roda nos tablets (como o N810) e no poderoso N900, celular top de linha da Nokia; e o Moblin, SO criado pela Intel para netbooks.

Sei que se trata de notícia velha, mas até agora com todas as pessoas que eu conversei ninguém sabe me explicar o porquê dessa fusão. É sabido que a Nokia estava sambando um pouco na questão de SO: o Symbian sempre caiu muito bem em celulares comuns, mas em smartphones (principalmente em celulares totalmente touch) a coisa não andava tão bem assim. Por conta dessas escorregadas ela abriu seus horizontes e alavancou o Maemo, que parecia que vinha para ficar. O N900 veio, ele é meio tijolão, mas possui um bom hardware, é mais estável e mais rápido que o Symbian, então valia a pena crescer com ele. E, 18 meses depois de lançá-lo, vem com essa notícia de fazer mais um sistema operacional. Por quê, ora bolas?

Decidi então pesquisar na Internet a opinião de usuários proprietários de aparelhos com Maemo instalado. A opinião quase sempre é a mesma: o SO é excelente, ainda incipiente, mas funciona bem no dia-a-dia. Não existe reclamação como existe dos usuários do N97. Ainda tentando entender o porquê, a melhor resposta que obtive foi de um amigo meu que é 'Nokia lover', em que crê que a chave está em três palavras chaves: desenvolvimento de aplicativos. Desde o anúncio, ambas empresas se esforçam em ressaltar de que desenvolver para o MeeGo será mais simples, mais portável e com um ambiente de desenvolvimento mais intuitivo. Alegam inclusive que permitirá portar aplicativos feitos em Linux desktop para dentro do dispositivo, e que todos os programas já desenvolvidos podem ser rodados nele sem perda de compatibilidade.

Isso só vem confirmar a tendência que o mercado já está mostrando há tempos: para que o celular 'pegue', ou seja, que ele seja aceito pelo público em geral, e que as pessoas queiram usá-lo, tem que haver uma grande variedade de aplicativos para ele. Depois de tudo que a Apple fez, criando um ambiente mais simples para desenvolvimento de aplicativos, agora é hora das outras empresas correrem atrás da maneira que podem.

Isso gera alguns benefícios e alguns problemas: como benefício, toda iniciativa para criar ambientes de desenvolvimento mais amigáveis é sempre bem vinda. Na lista dos problemas, pesa a indefinição da Nokia. Estive em um evento da Sony Ericsson em São Paulo, que agora também tem celulares em Symbian. Quando os desenvolvedores eram perguntados do porquê não desenvolverem aplicativos para Symbian, a resposta era sempre a mesma: nem a Nokia se decide se continua com ele ou não. Por que desenvolver pra algo que está fadado e que nem se sabe se estará rodando nos celulares que forem lançados daqui a 2, 3 anos? Isso sem contar o Maemo, que nem chegou no Brasil e já será descontinuado.

Por essas e outras que o iPhone e o Android deslancham, enquanto Nokia e Microsoft continuam ficando pra trás. Enquanto o sistema operacional do Google cresce, e o da Apple aumenta sua participação no mercado, os grandes players que já estavam jogando esse jogo vão perdendo terreno. E é bom que botem logo o bloco na rua, ou vão perder o bonde e ficar para trás.

Leia também:

• Vivo no mercado de venda de aplicativos
• Nokia N97: páreo para o iPhone?
• Como retirar o joystick do Cine Mobits do seu Nokia

Confira essa novidade e veja o que ainda está por vir.

Atualização (13 de Maio de 2010): Como poderão ver, o site do Globoesporte.com sofreu profundas alterações e com isso, influenciou no funcionamento do app que foi temporariamente retirado da App Store enquanto as adaptações são realizadas. A expectativa é relançar o app até a Copa para que todos possam curtir os jogos sem problemas. Aguardem mais novidades.

Lançada neste último dia 16, o app do Globoesporte.com é um presente para os fanáticos por futebol que poderão ficar ligados nas principais novidades deste esporte no Brasil e no mundo. Para baixar o aplicativo, clique aqui.

Clubes do Brasil

Esta primeira versão traz o editorial dos principais times do Brasil com os destaques do dia, últimas notícias e lista completa de jogos.

Todo esse conteúdo baseado na qualidade do jornalismos esportivo do Globoesporte.com com textos e fotos das últimas novidades do seu time do coração.

Campeonatos

Os torcedores de São Paulo terão a oportunidade de acompanhar o andamento do Campeonato Paulista com a classificação, a tabela de jogos e artilharia completa.

Nas próximas versões, já estão previstas as coberturas do Brasileirão e, claro, da Copa do Mundo.

Tempo Real

Este é o ponto alto da app. O fãs vão poder acompanhar lance-a-lance todas as partidas cobertas pelo Globoesporte.com.

Além dos lances, escalação e gols, os torcedores poderão assistir aos vídeos da partida. Sim, VÍDEOS! E não apenas dos gols, mas também dos lances importantes, Show do Intervalo e notícias dos momentos anteriores à partida.

E vem mais por aí

Além dos campeonatos mencionados anteriormente, estamos trabalhando em outras novidades para as próximas versões. Fique ligado no blog da Mobits para saber das notícias em primeira mão.

O modelo de venda de aplicativos criado pela Apple deu tão certo, que outras grandes marcas (Nokia, Google, etc) também seguiram a onda. Agora chegou a vez das operadoras de celulares embarcarem nessa também. Por aqui, a Vivo anunciou recentemente seu modelo.

A Vivo irá permitir que os desenvolvedores possam além de vender seus aplicativos, também utilizar sua plataforma de desenvolvimento em seus produtos. Dessa forma, os desenvolvedores poderão agregar nas suas apps o uso das APIs de envio de mensagens SMS, MMS e uso de WAP-PUSH.

Os aplicativos poderão ser colocados à venda dos seguintes modos: como beta, sendo pré-lançamentos a preços menores, ou pelo processo completo de certificação para aí sim ser comercializado na loja virtual Downloads Store. A divisão da receita para a venda de aplicativos será 70% para o desenvolvedor e 30% para a Vivo. E no caso de uso de suas APIs, 10% para o desenvolvedor e 90% para a operadora.

Com a entrada das operadoras nesse mercado de venda de apps, os desenvolvedores ganham mais uma opção para criar seus produtos, aumentando a diversidade de produtos para os usuários finais.

Para ingressar como desenvolvedor é necessário requisitar convite para a Vivo. Para saber mais acesse o portal: http://desenvolvedores.vivo.com.br/.

Leia também:

• Nexus One versus iPhone

O Cine Mobits em parceria com o Kinoplex irá sortear 10 pares de ingressos!

Para mais informações, acesse: http://www.cinemobits.com.br/promocoes

Acredite, podemos sim! E como descobri isso? Durante esta semana, no desenvolvimento de um projeto, precisávamos de um algoritmo que convertesse uma imagem colorida em preto e branco. Após algumas pesquisas, encontramos o algoritmo do Chris Greening, porém o mesmo estava em C++. Pesquisando mais ainda, vimos que o compilador de Objective-C permite misturar C++ e Objective-C, porém com algumas ressalvas.

Para conseguir compilar código C++, o seu arquivo ".m" precisa ter a extensão ".mm". Mas atenção: os arquivos que tiverem tanto código C++ quanto Objective -C precisam também ter a extensão ".mm".

Observação: uma vez que seu código compile C++, código em C não é mais compilado. Para resolver esta questão, basta usar extern:

extern "C" {  #import "ImageUtils.h" }

Aqui vai um "Alo Mundo" que mistura tanto C++ quanto Objective-C como exemplo. Para testar, você pode colar o exemplo no main.mm.

#import <Foundation/Foundation.h> 

class AloMundo { 
    private: 
        id saudacao; 

    public: 
        AloMundo() { 
            saudacao = @"Alô, mundo!"; 
        } 

        AloMundo(const char* texto) { 
            saudacao = [[NSString alloc] initWithUTF8String:texto]; 
        } 

        void imprimir()  { 
            printf("%s\n", [saudacao UTF8String]); 
        } 
};

A classe AloMundo acima é em C++, porém se utiliza de código em Objective-C. Ela simplesmente tem a função de imprimir a saudação.

@interface Saudacao: NSObject { 
        AloMundo *aloMundo; 
}

- (id)init; 
- (void)dealloc; 
- (void)saudar; 
- (void)saudar:(AloMundo *)saudacao; 

@end 

@implementation Saudacao
- (id)init { 
    if (self = [super init])
        aloMundo = new AloMundo(); 

    return self; 
}

- (void)dealloc { 
    delete aloMundo; 
    [super dealloc]; 
} 

- (void)saudar { 
    aloMundo->imprimir(); 
} 

- (void)saudar:(AloMundo *)saudacao{ 
    saudacao->imprimir(); 
} 

@end

Já neste código acima, temos a classe Saudacao em Objective-C. Aqui também há código em C++, como podemos observar no init, que instancia a classe AloMundo.

int main() { 
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; 

    // Objective-C
    Saudacao *saudacao = [[Saudacao alloc] init]; 
    [saudacao saudar];                          // ------> Alô, mundo! 

    // C++
    AloMundo *aloMundo = new AloMundo("Hello, world!"); 
    [saudacao saudar:aloMundo];       // ------> Hello, world! 

    delete aloMundo; 
    [saudacao release]; 
    [pool release]; 

    return 0; 
}

No main, percebemos as duas formas de chamar o método de imprimir a saudação. Atenção para a forma de trabalhar com a memória. Em Objective-C, utilizamos alloc e release. Já em C++, new e delete.

Como mencionei acima, combinar as duas linguagens tem ressalvas, então tenha como premissas:

• não é possível usar a sintaxe Objective-C para chamar um objeto C++;
• não é possível adicionar construtores ou destrutores em Objective-C;
• cuidado com as palavras reservadas de cada linguagem;
• uma classe C++ não pode herdar de uma classe em Objective-C e vice-versa;
• cada linguagem cuida de suas exceções, ou seja, uma exceção lançada em C++ não pode ser tratada em Objective-C e vice-versa.

Eu acredito que saber que podemos combinar as duas linguagens facilitará a vida de muitos desenvolvedores, pois já existem vários algoritmos prontos em C++ que são bastante úteis e não precisarão mais serem "traduzidos" para Objective-C.

Até mais!

Leia também:

• UIPickerView circular - "Gambiarra oficial" da Apple
• Dica: como obter o número do iPhone através de um aplicativo

O post do Felipe sobre testes em iPhone, escrito em janeiro do ano passado, serviu como parâmetro para vários projetos nossos aqui na Mobits. Só depois de um bom tempo utilizando o framework do Google, descobrimos lendo posts do Matt Gallagher no Cocoa with love que o framework nativo do Xcode estava disponível para projetos em iPhone.

Pesquisando na internet, decidimos implementar um projeto utilizando o framework padrão. Este post visa mostrar como configurar seu projeto para iPhone usando o framework nativo e compará-lo com o GTM. Por enquanto, estamos lidando apenas com teste unitários. Em um post futuro comentamos sobre Mock e como adicioná-lo ao seu projeto.

Configuração

Uma vez criado o projeto, você deve criar um novo target para o projeto. Clique com o botão direito em Target > Add > New Target....

Como template, escolha Unit Test Bundle. Escolha um nome para o target (sugestão: Testes Unitarios) e clique em Finish.

Agora, arraste o target original para dentro do target de teste, para criar dependência (forçar o aplicativo a dar build no projeto antes de executar os testes). Após fazer isso, o target deve ficar assim:

Pronto! Com isso você já tem o suficiente para rodar seus testes. Mas pode ser que você queira algo a mais, então vamos ao próximo passo que pode ser muito útil nos seus testes.

Debug

Esta foi a parte mais complicada de fazer funcionar. Depois de muitas indas e vindas em diversos sites, conseguimos configurar o debug (funcionando com breakpoint). Assim você pode correr passo-a-passo as linhas de código dos seus testes caso precise. Vale ressaltar que o debug não funciona caso tenha ocorrido erro de compilação, mas funciona perfeitamente em caso de falhas ocorridas nos testes.

Mas vamos ao que interessa: primeiro, crie um executável para o projeto (Project > New Custom Executable...).

Na janela que se abre, escolha o nome do executável. Ele deverá executar o otest, um programa de termnal que serve para depurar o código das classes em Objective-C. Ele deve ser específico para o SDK do iPhone que você utiliza no projeto. Para saber onde ele está e qual versão você deve utilizar, vá no terminal e digite:

find /Developer -name otest

Eu obtive os seguintes resultados:

/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/Developer/usr/bin/otest
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.2.sdk/Developer/usr/bin/otest
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.sdk/Developer/usr/bin/otest
/Developer/Tools/otest

Que fique bem claro que o último não serve para projetos em iPhone. No nosso caso, usamos o segundo (3.1.2). Clique em Finish. Agora precisamos configurar os argumentos do executável na janela que aparece. A imagem abaixo mostra como eles devem ser configurados:

Na seção dos argumentos, você deve obedecer a ordem em que eles estão escritos. O segundo argumento deve ser o nome do produto gerado pelo target de testes que você utiliza (veja no grupo Products). Na seção de variáveis, utilize os seguintes valores:

Cuidado com a última variável: ela deve ser a mesma versão do SDK utilizado com o otest. Feito isso, você já possui a configuração necessária para "debugar" seus testes. Tudo que você precisa fazer é configurar o executável como o padrão (Project > Set Active Executable). Marque os breakpoints que achar necessário e execute com "Build and Debug".

Comparações

Com o framework configurado e com vários casos de teste já implementados, fica inevitável a comparação entre o framework padrão e o GTM. Algumas diferenças são notadas logo de cara.

• Menos métodos de teste: foi um susto ao ver que o framework padrão não tinha o STAssertEqualStrings. Mas nada que assustasse muito: o STAssertEqualObjects servia para o mesmo propósito. No final das contas, não houve nenhum teste que não conseguimos fazer por não existir método para tal.

• Bundle: Isso é ponto positivo para o GTM. Para acessar arquivos no ambiente padrão você não utiliza o [NSBundle mainBundle]. Para fazer funcionar, tivemos que configurar no target (na aba Properties, no campo Identifier) um identificador que pudesse ser referenciado no código. Se, por exemplo, você colocar lá um identificador "com.mobits.caricas.tests", basta chamar o bundle identificado por essa string: [NSBundle bundleWithIdentifier:@"com.mobits.caricas.tests"]. É óbvio que isso nos causou alguns problemas nos testes, principalmente nos casos em que no target do aplicativo eu tinha que rodar em um bundle e no target de testes eu tinha que rodar em outro. A solução foi utilizar diretivas de pré-compilação.

• Build Results: nisso o framework padrão ganha de lavada do GTM. Enquanto neste os erros aparecem todos duplicados, e listados diretamente na lista dos resultados do build, naquele aparece bem organizado, cada erro apontado hierarquicamente dentro do seu específico caso de teste.

Exibição dos erros no GTM: duplicado

Exibição dos erros no framework padrão: visão hierárquica dos testes

Conclusão

Por ser mais simples de configurar, por exibir melhor os erros dos testes e por não ter certas mandingas que o GTM tem (não poder rodar os testes com o iPhone Simulator aberto, por exemplo), a escolha é o framework padrão do Xcode. Os métodos a mais de teste do GTM não foram um diferencial tão grande que pesasse em favor dele, mas talvez aqueles que o utilizam e desejam migrar vão ter alguns problemas de adaptação, mas nada que seja o fim do mundo.

Em um post futuro eu comento outra parte importante nos testes, a técnica de Mock Objects, como configurá-lo e como utilizá-lo em seus testes. Ah, e se você encontrou algum erro ao tentar configurar o ambiente, adiciona um comentário aqui, pode ser que já tenhamos passado por isso e saibamos como solucionar.

Grande abraço!

Leia também

• Testes no iPhone
• Testes de interface no iPhone SDK com o UIRecorder
• UIPickerView circular - "Gambiarra oficial" da Apple