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

A Mobits acabou de desenvolver um aplicativo que consulta e armazena informações de veículos e condutores em conjunto com a Kognitus, empresa incubada na COPPE/UFRJ. O aplicativo exibe também as restrições dos veículos e condutores, como excesso de pontos na carteira de habilitação, IPVA não pago, etc. Além disso, auxilia os fiscais de trânsito exibindo as ações que devem ser tomadas para cada tipo de restrição encontrada, guardando essas consultas com a posição GPS e foto para futuras auditorias.

Para consultar os veículos, o aplicativo é dotado de um módulo de reconhecimento de placas, capaz de identificá-las tirando uma foto, sem a necessidade de digitação.

O módulo de reconhecimento de placas foi desenvolvido pela Kognitus com tecnologia própria. Coube à Mobits o desenvolvimento do aplicativo mobile e do servidor web de comunicação, este último desenvolvido em Ruby on Rails.

O aplicativo foi financiado pela FAPERJ e futuramente será apresentado para órgãos como o DETRAN.

Com o lançamento do Windows Phone 7, a Microsoft resolveu romper com o passado descontinuando o antigo Windows Mobile. Ainda não se sabe sobre como serão as funcionalidades finais do novo sistema, mas as minhas maiores dúvidas são: como será a plataforma de desenvolvimento? Será que o novo sistema rodará os aplicativos de Windows Mobile? Se não, como migrá-los?

O que sabemos é que o Kernel do novo sistema é o Windows CE 6.0, uma evolução do Kernel do Windows Mobile que usava o Windows CE 5.0. O que mudou muito foi a interface, que foi totalmente remodelada para ficar mais finger-friendly e parecida com a do Zune HD para fazer frente com a interface do iPhone e demais concorrentes. Além disso ela também não poderá ser mais customizada por cada fabricante ou operadora.

Sobre os aplicativos do Windows Phone, a Microsoft deixou claro que os detalhes só seriam revelados futuramente. Contudo ela já revelou que os jogos poderão ter integração com a plataforma do Xbox LIVE e que o sistema terá um Marketplace, que pelo layout pareceu mais parecido com o do Zune do que com o Marketplace do Windows Mobile.

Segundo rumores do Engadget a nova plataforma não deverá rodar os antigos aplicativos diretamente, nem deve permitir atualização dos antigos dispositivos Windows Mobile para o novo sistema, o que é muito ruim para os desenvolvedores que terão que migrar o seus aplicativos para a nova plataforma e para os usuários finais. É realmente um novo sistema..

Os desenvolvedores já estão especulando sobre a plataforma de aplicativos e ferramentas. A expectativa é que o novo sistema seja baseado em 3 tipos de plataformas já existentes da Microsoft - o Silverlight para interfaces gráficas ricas, animações, etc; o XNA para desenvolvimentos de jogos, como no Zune e o Compact Framework usado no Windows Mobile para aplicações com formulário e componentes visuais diversos. Outra suposição é que as restrições do sistema para chamadas de APIs privadas aumentarão bastante, impedindo que os aplicativos tenham acesso direto a diversos recursos como tinham no sistema antigo. A plataforma de desenvolvimento deve ser o Visual Studio 2010 em conjunto com o Express Blend e o Windows Phone emulator a ser revelado.

Todas as dúvidas, contudo, só serão esclarecidas mesmo no evento MIX10, de 15 a 17 de março, onde a Microsoft ficou de revelar mais detalhes para a comunidade de desenvolvedores.

Só nos resta aguardar pelas notícias e torcer para que a Microsoft, desta vez, desenvolva um sistema que não seja descontinuado e permita que, tanto os aparelhos quanto os aplicativos antigos, possam ser migrados sem muito custo para as versões subseqüentes.

Leia também:

• Interfaces mais atraentes no Windows Mobile
• Mobits desenvolve mais um aplicativo em Windows Mobile
• Agendamento de programas em Windows Mobile