Curtis Stone, astro de “Chef em domicílio” e “Top Chef: Masters”, apresenta mais um aplicativo da I.ndigo para iPhone.

Hyvee é uma rede de supermercados com mais de 200 lojas espalhadas pelos Estados Unidos. Agora, com o aplicativo iPhone seus clientes poderão:

- Visualizar as ofertas da sua loja favorita
- Localizar a loja mais próxima
- Montar e compartilhar sua lista de compras
- Localizar produtos dentro da loja (inclusive com comando de voz)
- Reportar produtos que estão esgotados
- Ter acesso a dezenas de receitas e adicionar os ingredientes à sua lista
- Comprar através do celular
- Acessar cupons de desconto e muito mais.

O ponto máximo do app está na localização de produtos dentro da loja, que pode ser feito inclusive através de comando de voz.

A customização do aplicativo conforme a loja favorita do usuário, é outra funcionalidade extremamente relevante e que costuma passar batida na maioria dos aplicativos.

Baixe o Hyvee para iPhone e nos diga o que você achou.

O aplicativo lançado no mês passado une peças reais de LEGO e um jogo interativo para iPhone/iPod. Além de ser multi-player o que fez a gente gostar ainda mais do app.

george.lego.com

Logo após o anúncio da primeira versão do iPhone, o New York Times divulgou uma pesquisa apontando um surpreendente resultado. Segundo o estudo, existia um grande número de pessoas de baixa renda comprando o aparelho, considerado caro. A explicação para isso se devia pelo fato de que o custo era pequeno se comparado com de um PC com serviço de internet, tornando-se uma opção de acesso, com uma velocidade razoavelmente boa e pagando não muito mais por mês do que já pagavam em seus celulares da época. Este mesmo fenômeno que aconteceu nos Estados Unidos no lançamento do primeiro iPhone está prestes a se repetir no Brasil, com o surgimento dos primeiro planos de internet móvel pré-paga, tornando-a mais acessível.

Este cenário de quatro anos atrás agora é parte de uma tendência, que deve impactar no desenvolvimento de conteúdo das empresas para a internet.

O relatório “Adoção e uso dos smartphones”, divulgado em julho de 2011 pela Pew Internet, apresentou um perfil dos usuários de smartphones nos Estados Unidos, tendo como principal objetivo a descoberta do motivo desta popularização.

A informação mais importante do estudo é a de que um quarto dos usuários de smartphones dependem exclusivamente destes dispositivos para ter acesso à internet. Além disso, descobriu-se que 35% dos adultos norte-americanos possui um smartphone, sendo que a maioria tem menos de 50 anos e renda inferior a 30 mil dólares anuais.



Quando perguntado qual dispositivo normalmente usa para acessar a internet, 25% dos usuários de smartphones disseram que na maioria das vezes prefere utilizar o seu telefone, mesmo muitos deles possuindo outras fontes de acesso.

A pesquisa evidencia um movimento que transformará os dispositivos móveis como meio principal de acesso à Internet no mundo, algo já real nos EUA.

É preciso que as empresas levem em conta esta tendência de acesso em telas menores ao projetarem seus sites corporativos e/ou aplicações móveis. Empresas atualizadas permitem interatividade facilitada a partir de smartphones e tablets. Quem não acompanhar esta tendência vai perder espaço.

Fazer um site ou aplicativo usáveis em um dispositivo móvel não é tão difícil, complicado é fazer algo que as pessoas realmente o queiram usar. O desafio está lançado!

De acordo com dados divulgados esta semana no site da Anatel, referentes ao mês de julho de 2011, a quantidade de aparelhos 3G chegou à marca de 22,77 milhões de unidades ativas, alcançando 11,69% da população brasileira. Esta informação vem sinalizar um aumento de 456%, comparado às 4,09 milhões de unidades existentes ao final do mês de dezembro de 2009. É importante salientar que nestes números não estão inclusos os acessos 3G via modens.

A previsão, no início do ano era que, até o final de 2011, o total de aparelhos 3G chegasse a 35 milhões, o que representaria um aumento de 139,50% em relação a 2010.

Com relação às plataformas, o Brasil começa a acompanhar a tendência do mercado mundial e já tem o Android como plataforma mais utilizada, tendo 37,1% de participação no mercado nacional e 39% no global. O Symbiam, da Nokia, continua em segundo lugar dentro do Brasil, porém, com o tempo deve acompanhar a queda mundial e perder a posição para o iOS da Apple, que já possiu quase 10% do mercado.

Quantidade de Aparelhos 3G – Fonte: Anatel

A liderança no setor continua sendo da Claro, com 40,57% de participação no mercado, mas vale ressaltar que a empresa que mais cresceu em 2011 foi a TIM, que conseguiu quase dobrar a quantidade de assinantes em apenas 7 meses, atingindo 5,23 milhões de usuários e 23% de participação do mercado. Vivo e Oi conseguiram manter um ritmo forte de crescimento, um pouco acima do próprio mercado, enquanto a Claro começa a mostrar indícios de que, ainda este ano, poderá deixar de ser a primeira colocada.

Na semana passada completamos 15 dias do lançamento dos aplicativos iPhone e iPad que fizemos para a NBC – o The Royal Wedding by NBC News.

O fato do aplicativo ter sido lançado durante os programas de maior audiência da televisão norte-americana, nos rendeu uma repercursão que não acreditávamos ser possível em tão pouco tempo, em pouquíssimas horas nosso app já figurava entre os vinte mais baixados da App Store Americana, chegando ao segundo lugar entre os aplicativos da categoria lifestyle.

Os dias que sucederam o lançamento foram de mais surpresas ainda, figuramos entre os aplicativos recomendados pela Apple nas seções “What’s Hot” e “New and Noteworthy” ao lado do Justin Bieber e da Oprah (rs). Outro fato curioso foi a criação de uma área inteira de destaque na App Store para aplicativos voltados à cobertura do casamento real.

Nosso app em destaque no New and Noteworthy

Área de destaque criada pela Apple para Apps do Royal Wedding

A notícia do aplicativo também repercurtiu em alguns sites que gostamos muito como o appolicious e o mobilepedia, no youtube a NBC publicou um vídeo com o Vice-Presidente deles contando detalhes do desafio de lançar um aplicativo tão completo, em tão pouco tempo.

O aprendizado com o projeto foi grande também para o nosso time, por exemplo em mobile-advertising, tivemos a oportunidade de lidar de perto com o iAd aproveitando todo o buzz criado pela NBC e compará-lo com a busca de patrocínios independentes. Tem sido interessante também analisar o padrão de comportamento e o país de origem dos usuários que baixaram o aplicativo.

Estamos agora ansiosos para acompanhar a evolução de usuários com a proximidade do casamento, e fiquem de olho para acompanhar as próximas novidades que vamos lançar até lá.

Recentemente caímos em uma situação em que necessitávamos testar uma aplicação iPhone (SDK 4.0) tentando acessar uma aplicação web via UIWebView. Porém, havia um problema: todas as páginas do servidor eram fornecidas por conexão HTTPS, mas o certificado não era válido.

Uma forma de resolver este problema foi usando o método estático setAllowsAnyHTTPSCertificate:forHost: da classe NSURLRequest, que faz parte da API privada da Apple. Este método permite que você especifique quais host podem ter seu certificado HTTPS aceito pela aplicação.

Usando o método acima há grandes chances de ter seu app rejeitado, mas em uma situação de teste a alternativa funciona muito bem.

Você deve usar este método antes de fazer o request do UIWebView, como o seguinte:

NSURL *url = [[NSURL alloc] initWithString:@”https://www.something.com”];
[NSURLRequest setAllowsAnyHTTPSCertificate:YES forHost:[url host]];
[webView loadRequest:url];

Isto seria suficiente, mas você verá que seu código mostrará uma mensagem de warning dizendo “‘NSURLRequest’ may not respond to ‘+setAllowsAnyHTTPSCertificate:forHost:’”. Se você quer resolver isso, adicione o seguinte ao final do arquivo .h que corresponde ao .m que você está trabalhando:

@interface NSURLRequest (Certificates)
+ (void)setAllowsAnyHTTPSCertificate:(BOOL)allow forHost:(NSString*)host;
@end

Este código sobrecarrega a interface do método da classe NSURLRequest, mas não iremos reimplementá-lo, então a implementação existente na API privada pode ser usada.

Como pode ser visto, embora o uso da API privada da Apple não seja permitido, ele pode ser bastante útil em algumas situações.

Espero que este post tenha ajudado. Obrigado!

A Airbnb é uma empresa relativamente nova, que foi fundada a partir de um simples conceito – conectar pessoas que procuram um lugar para ficar e pessoas que têm um espaço livre para emprestar/alugar – e que recentemente atingiu a incrível marce de um milhão de noites reservadas. É uma marca impressionante para uma empresa que tem menos de cinco anos de vida, e um salto gigante para o movimento de consumo colaborativo que segundo Rachel Botsman co-autora do livro “What’s Mine Is Yours: The Rise of Collaborative Consumption” está em sua “fase incipiente” e tem o potencial de ser um catalisador cultural e económico para as mudanças nas formas que vivemos e fazemos negócios.

O sucesso da Airbnb e de seu aplicativo – que já atingiu em poucos meses mais de 160.000 de downloads no itunes – é um bom sinal por uma série de razões. Em primeiro lugar, é simplesmente gratificante ver página após página de opiniões positivas sobre as experiências de seus usuários. Por mais absurdo que possa parecer, em sua maioria, estranhos na Internet tendem a se comportar bem. “Eu vou passar a noite na casa desse cara que eu acabei de conhecer” não soa mais tão assustador quanto soaria alguns anos atrás. Na verdade soa mais para “Eu vou passar a noite na casa de uma cara que tem uma grande sala com vista para o mar e 180 reviews com cinco estrelas”.

O sucesso do Airbnb continua a evidenciar que o consumo colaborativo não é apenas algo que as pessoas procuram quando estão querendo economizar, ou quando estão sem opções (de hospedagem no caso) – claro, muita gente usa o Airbnb, para encontrar um bom quarto com preços comparativamente mais baixo – mas há muitos que usam o aplicativo para encontrar lugares que custam milhares de dólares por noite.

Se a empresa era apenas dirigida por uma resposta a um mau momento da economia, agora que os mercados estão em alta, seria de esperar que os negócios do Airbnb fossem pelo menos diminuir a velocidade de crescimento, mas ao invés disso, eles estão crescendo – e rápido. A companhia reportou em janeiro passado um de 65%.

No que diz respeito ao modelo de negócio o Airbnb leva uma porcentagem de 10% do preço de reserva, o que significa que 90% do dinheiro das mais de um milhão de noites reservadas foi diretamente para as mãos dos usuários do aplicativo.

Os Estados Unidos sempre foram amplamente criticados pelos excessos do capitalismo e pela cultura gananciosa de suas grandes corporações, mas parece que os emprendedores de crowd-sourcing e os beta-empreendedores como a Airbnb encontraram um meio-termo onde todos saem ganhando.

Então parabéns, Airbnb. Compartilhar é cuidar de fato.

fontes: JustMeans, South by South West, RCR Wireless

Following the last post, Core Data over SQLite Performance Tests – Part 2, when we began performance tests with Core Data, now we continue with the results of this analysis.

As we defined before, this test will show the performance of 4 situations (see details on the previous post):

1. Insert without join tables;
2. Inserts with tables;
3. Select without join tables;
4. Select with join tables.

The previous post showed the first 2 situations. This time we will cover the last 2 (selects).

1. Select without join tables

This test tries to execute selects without joins in 2 ways:

• Fetch by object’s attributes;
• Fetch by identifier.

In each case, we see how the time to execute the select varies with the number of registries of the table (from 1 to 10000):

a) Fetch by object’s attributes

As we can see on the chart, when fetching by an attribute that is not indexed the time needed to execute the select varies almost linearly with the number of registries of the table. So, it is easy to think on how the performance of your table is getting worst with the time.

b) Fetch by identifier

This case shown us that fetching by the identifier (indexed), the time to fetch almost do not change with the number of registries, once the average time to fetch was almost equal the min time.

Conclusion

This tests resulted on the following table:

As we can see, for simple selects (without joins) when possible we should use identifiers to fetch, but, if we need to fetch by an attribute, it’s not hard to think about the performance, once it increases linearly with the size of the table.

2. Selects with join tables

This test shows how the time to execute a select increases as the number of join tables (in each select) and number of rows increases. The number of joins varies from 0 to 4.

a) Joins quantity: 0

This test has no joins, so the results is the same from the previous test when fetching by an attribute.

b) Joins quantity: 1

As might be expected, with 1 join the average time to a insert was much worst, about 4.27 times greater than with 0 joins.

c) Joins quantity: 2

With 2 joins we needed almost the same time to process the select, as expected, once the fetching engine has already entered on the process’ join step, what is not needed with 0 joins.

d) Joins quantity: 3

With 3 joins the average time was slightly worst again, as we might expect.

e) Joins quantity: 4

Again, with 4 joins the average time was slightly worst, as we might expect.

Conclusion

The following table results from the tests:

As we can see, we have a great variance from 0 to 1 join, but a small variance as the number of joins increases, due the way the select engine works.

This post, and the previous one, showed performance tests for Core Data that bring us information to analyse when use it in a project and what impact we would have when using it.

The next posts will present our analysis over the Magical Panda Active Record framework. We expect you are anxious as we are. Stay tuned!

This post is also available in Portuguese: Testes de performance do Core Data sobre SQLite – Parte 3.

Seguindo nosso último post, Testes de performance do Core Data sobre SQLite – Parte 2, quando iniciamos testes de desempenho com o Core Cata, agora continuaremos com os resultados desta análise.

Como definimos anteriormente este teste mostrará o desempenho em 4 situações (veja detalhes no post anterior):

1. Inserções sem relacionamentos;
2. Inserções com relacionamentos;
3. Buscas sem relacionamentos;
4. Buscas com relacionamentos.

O post anterior mostrou as 2 primeiras situações. Este post mostrará as últimas duas (selects).

1. Buscas sem relacionamentos

Este teste tenta executar buscas sem joins de 2 formas:

• Busca por atributo;
• Busca por identificador.

Em cada caso, vemos como o tempo para executar a busca varia com o número de registros da tabela (de 1 até 10000):

a) Busca por atributo

Como podemos ver no gráfico, quando buscando por um atributo que não esteja indexado o tempo necessário para executar o select varia quase linearmente com o número de registros da tabela. Assim, é fácil pensar em como o desempenho de sua tabela está piorando com o tempo.

b) Busca por identificador

Este caso mostra que buscando pelo identificador (indexado), o tempo de busca praticamente não muda com o aumento do número de registros da tabela, uma vez que o tempo médio de busca foi quase igual ao tempo mínimo.

Conclusão

Estes testes resultaram na seguinte tabela:

Como podemos ver, para selects simples (sem joins) sempre que possível devemos usar identificadores para a busca, mas, se precisarmos buscar pelo identificador, não é difícil pensar no desempenho, uma vez que ele aumenta linearmente com o tamanho da tabela.

2. Buscas com relacionamentos

Este teste mostra como o tempo para executar um select aumenta com o número de joins (em cada select) e o número de linhas. O número de joins varia de 0 a 4.

a) Relacionamentos: 0

Este teste não tem relacionamentos, então o resultado é o mesmo do teste anterior quando buscando por um atributo.

b) Relacionamentos: 1

Como esperado, com 1 join o tempo médio foi bem maior, 4,27 vezes maior que com 0 joins.

c) Relacionamentos: 2

Com 2 joins precisamos de quase o mesmo tempo de processar o select, como esperado, uma vez que a engine de busca já entrou o passo de join do processo de busca, o que não ocorre com 0 joins.

d) Relacionamentos: 3

Com 3 joins o tempo médio foi levemente pior novamente, como esperado.

e) Relacionamentos: 4

Novamente, com 4 joins o tempo médio foi levemente pior, como esperado.

Conclusão

A seguinte tabela resulta dos testes:

Como podemos ver, temos uma grande variação de 0 para 1 join, mas uma pequena variação conforme o número de joins aumenta, devido a funcionamento da engine de busca.

Este post, e o anterior, mostraram os testes de desempenho para o Core Data, que nos trouxeram informações para analisar quando usá-lo em um project e qual impacto teríamos quando usando-o.

Os próximos posts apresentarão nossa análise sobre o framework Magical Panda Active Record. Esperamos que você esteja ansioso como nós estamos.

Este post também está disponível em Inglês: Core Data over SQLite Performance Tests – Part 3

Visão Geral

Segundo site do Cocos2d, Cocos2d for iPhone é um framework para desenvolver jogos 2D, demos e outras aplicações gráficas/interativas. Ele é baseado no padrão cocos2d: ele usa os mesmos conceitos, mas em vez de Python ele usa Objective-C.

Para os desenvolvedores do Framework, o Cocos2d for iPhone é:

• Fácil de usar: ele usa uma API familiar e vem com uma série de exemplos
• Rápido: ele usa boas práticas do OpenGL ES e otimiza estruturas de dados
• Flexível: ele é fácil de ser integrado com outras bibliotecas
• Grátis: é open source, compatível tanto com jogos abertos quanto fechados
• Comunidade: o cocos2d tem uma comunidade ativa, grande e amigável (fórum, IRC)
• Aprovado pela AppStore: mais de 550 jogos na AppStore o utilizam, incluindo vários jogos bem vendidos

O Cocos2d vem com uma API que torna simples a criação de projetos baseados no OpenGL ES, mesmo se você não é um expert com programação em OpenGL, uma vez que tem um bom encapsulamento de algumas funcionalidades bastante usadas.

Um ponto negativo em usar este tipo de ferramenta é que algumas vezes você se perde quando ele automatiza algo que você não gostaria que fosse feito. Criar uma camada transparente de OpenGL ES usando o Cocos2d tem esse problema. Uma vez que muitas pessoas da comunidade tiveram esse problema, resolvemos postar sobre isso.

Criando uma camada transparente do OpenGL ES Layer com o Cocos2d

Criar uma camada transparente de OpenGL ES com o Cocos2d v 0.99.4 não foi uma tarefa simples, uma vez que seu código template contém uma Macro para inicializar uma série de variáveis internas.

Se você ver a macro CC_DIRECTOR_INIT(), localizada no arquivo ccMacros.h, temos o seguinte:

#define CC_DIRECTOR_INIT()                                                        \
do {                                                                              \
                                                                                  \
    window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];     \
                                                                                  \
    if( ! [CCDirector setDirectorType:kCCDirectorTypeDisplayLink] )               \
        [CCDirector setDirectorType:kCCDirectorTypeNSTimer];                      \
                                                                                  \
     CCDirector *__director = [CCDirector sharedDirector];                        \
     [__director setDeviceOrientation:kCCDeviceOrientationPortrait];              \
     [__director setDisplayFPS:NO];                                               \
     [__director setAnimationInterval:1.0/60];                                    \
                                                                                  \
     EAGLView *__glView = [EAGLView viewWithFrame:[window bounds]                 \
                                      pixelFormat:kEAGLColorFormatRGB565          \
                                      depthFormat:0                               \
                               preserveBackbuffer:NO];                            \
                                                                                  \
     [__director setOpenGLView:__glView];                                         \
                                                                                  \
     [window addSubview:__glView];                                                \
     [window makeKeyAndVisible];                                                  \
                                                                                  \
 } while(0);                                                                      \

Como podemos ver, esta macro cria um EAGLView que tem um pixelFormat do tipo kEAGLColorFormatRGB565, que é de 16 bits. Para termos transparencia habilitada no nosso EAGLView precisamos criá-la com o formato kEAGLColorFormatRGBA8, que é de 32 bits.

Temos diversas formas de resolver isso, como alterar a macro ou inicializar tudo por nossa conta. O importante é certificar-se de alterar a linha:

EAGLView *__glView = [EAGLView viewWithFrame:[window bounds]                      \
                                 pixelFormat:kEAGLColorFormatRGB565               \
                                 depthFormat:0                                    \
                          preserveBackbuffer:NO];                                 \

para

EAGLView *__glView = [EAGLView viewWithFrame:[window bounds]                      \
                                 pixelFormat:kEAGLColorFormatRGBA8                \
                                 depthFormat:0                                    \
                          preserveBackbuffer:NO];                                 \

Com isso, teremos nossa camada OpenGL ES transparente quando usando:

glClearColor(0, 0, 0, 0);

Na linha acima, o último parâmetro indica a opacidade
(http://www.khronos.org/opengles/sdk/1.1/docs/man/).

É isso! Esperamos que você goste do Cocos2d for iPhone e que esta dica lhe seja útil!

Este post também está disponível em inglês: Cocos2d for iPhone 0.99.4 – OpenGL ES Transparent Layer