Facilitando a vida com o uso de literais no Objective-C

5 de Fevereiro de 2014

Facilitando a vida com o uso de literais no Objective-C

Literais são valores constantes fixados diretamente no código fonte.


"comida"      //C string literal  
@"comida"     //Obj-C string literal  
18              //integer literal    
18.0f           //float literal

Até a pouco tempo o Objective-C não possuía um suporte muito bom para literais. Isso significa que a declaração deste tipo de variável era extensa e cansativa.

O exemplo abaixo demonstra a declaração de um array simples:


NSArray *destilados = [NSArray arrayWithObjects:@"Whiskey", @"Tequila", @"Vodka", @"Conhaque"];

Apesar de não parecer muito trabalhoso, podemos perceber que as coisas começam a complicar um pouco mais quando queremos combinar dois arrays


NSArray *whiskeyBrands = [NSArray arrayWithObjects:@"Johnny Walker", @"Jack Daniels", @"Bells", @"The Famous Grouse"];
NSArray *vodkaBrands = [NSArray arrayWithObjects:@"Grey Goose", @"Stolichnaya", @"Skyy", @"Pyat Ozer"];
NSDictionary *drinksBrands = [NSDictionary dictionaryWithObjectsAndKeys:whiskeyBrands, @"whiskey", vodkaBrands, @"vodka", nil];

Utilizando literais podemos simplificar a declaração utilizando a sintaxe:


NSDictionary *petFoodBrandsByAnimal = @{
                                            @"whiskey" : @[@"Johnny Walker", @"Jack Daniels", @"Bells", @"The Famous Grouse"],
                                            @"vodka" : @[@"Grey Goose", @"Stolichnaya", @"Skyy", @"Pyat Ozer"]
                                        };
Podemos descrever essa forma de declaração como sendo um atalho que poupa tempo e permite declarar literais de uma forma muito mais simples e direta. Demonstrando a declaração de NSArray e NSDictionay de forma separada:

NSArray na forma tradicional
NSArray *array = [NSArray arrayWithObjects: …, … ];

NSArray usando literais


NSArray *array = @[ …, … ];

NSDictionay na forma tradicional


NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:object, key, …, nil];

NSDictionary usando literais


NSDictionary *dictionary = @{ key : value, … };

Além das facilidade de sintaxe para declarar variáveis, existem também alguns atalhos para acessá-las:

NSArray - Acessando um objeto da forma tradicional


id objectAtIndexTwo = [array objectAtIndex:2];

NSArray - Acessando um objeto utilizando a sintaxe simplificada


id objectAtIndexTwo = array[2];

NSMutableArray - Adicionando um elemento em um índice usando a sintaxe simplificada


NSMutableArray *mutableArray = [NSMutableArray array];
mutableArray[0] = @"jackalope";

NSDictionary - Acessando um objeto pela chave da forma tradicional


id objectForKey = [dictionary objectForKey:@"jackalope"];

NSDictionary - Acessando um objeto pela chave usando a sintaxe simplificada


id objectForKey = dictionary[@"jackalope"];

NSMutableDictionary - Atribuindo um objeto a uma chave usando a sintaxe simplificada


NSMutableDictionary *mutableDictionary = [NSMutableDictionary dictionary];
mutableDictionary[@"key"] = @"value";

Como NSArray e NSDictionary aceitam apenas objetos e não tipos primitivos como números, normalmente é necessário criar um NSNumber para somente depois poder adicioná-lo a um NSArray


NSNumber - Adicionando um NSNumber a um NSArray da forma tradicional 
NSInteger myNumber = 17;
NSNumber *myNumberObject = [NSNumber numberWithInteger:myNumber];
NSArray *myNumbers = [NSArray arrayWithObjects:myNumberObject];

NSNumber - Adicionando um NSNumber a um NSArray com a sintaxe simplificada


NSArray *myNumbers = @[@17];

Aplicações MVC Client-Side (Single-Page Applications)

3 de Abril de 2013

Olá

Recentemente participei do desenvolvimento do aplicativo Gooparties onde utilizamos uma arquitetura totalmente client-side utilizando o framework Backbone. Neste post vou falar um pouco sobre esse tipo de arquitetura, quais as características e como essa arquitetura se diferencia do tradicional MVC utilizado em frameworks server-side como Rails, ASP.NET MVC, Zend entre outros.

O que é uma arquitetura MVC client-side (também conhecida como single-page applications)?

Antes de começarmos a falar de aplicações client-side vamos dar uma olhada nos modelos mais conhecidos de aplicações web. No modelo tradicional (server-side) MVC temos os componentes Model, View e Controller sendo executados no servidor, gerando o html e enviando esse html para ser visualizado no browser do usuário. Nesse modelo o Model, Controller e View são executados no lado servidor.

Server Side MVC Image

Em um formato um pouco mais evoluído temos aplicações onde o html ainda é gerado no lado servidor mas são utilizadas técnicas como ajax para atualizar de partes da página ou funcionalidades implementadas em javascript em alguns componentes para melhorar a experiência do usuário evitando um reload completo da página a cada interação do usuário. Neste modelo o Model, Controller e View ainda são executados no servidor, mas algumas funcionalidades da View passam a ser executadas no lado cliente.

Hibrid Mode MVC Image

O terceiro modelo são as aplicações client-side. Nesse modelo a responsabilidade de controller e view são executadas no lado cliente. O Model passa a ter duas partes, uma executada no lado servidor, quer fornece a API e validações e outra executada também no lado cliente, que também fornece validações e informações sobre a estrutura do modelo.

Hibrid Mode MVC Image

Quais as vantagens de utilizar MVC client-side?

Melhor experiência para o usuário

A principal vantagem é um ganho muito grande no desempenho da aplicação. Como o browser não precisa fazer requisições, download e parser de páginas completas a cada interação do usuário o resultado é uma aplicação que responde muito mais rápido aos comandos. Aplicações construídas com a arquitetura client-side funcionam de uma forma tão natural quanto uma aplicação desktop instalada na máquina do usuário.

Melhor desempenho na transferência de dados

Existe também um ganho considerável em velocidade na transmissão dos dados, pois ao invés de trafegar o conteúdo html completo a cada interação do usuário, na arquitetura client-side o aplicativo completo é transferido na primeira requisição e as requisições seguintes são responsáveis por trafegar apenas os dados brutos entre o cliente e o servidor, normalmente no formato JSON. Este ganho é visível em aplicações móveis onde a velocidade na transferência dos dados normalmente é baixa.

Redução de carga no lado servidor

O aplicativo completo passa a ser fornecido através de arquivos html, css e javascript que podem ser comprimidos e distribuídos através de CDN's com facilidade. Após baixados pela primeira vez esses arquivos são mantidos em cache no browser do usuário. O servidor fica responsável apenas por fornecer uma API e enviar e receber os dados brutos no formato JSON. Dessa forma todo o processamento responsável por parsing dos dados e geração de templates fica no lado cliente e não mais no servidor, liberando recursos.

Facilidade de manutenção

Como aplicações client-side dependem apenas da API fornecida pelo servidor, as manutenções no lado servidor podem ser feitas de forma independente e transparente para o lado cliente (desde que não mude a API, obviamente). Da mesma forma, o lado cliente pode ser alterado sem a necessidade de alterar nada no lado servidor.

Gerenciamento de equipes

Como o lado cliente e o lado servidor passam a ser desenvolvidos de forma completamente independente, a única coisa necessária para os dois times trabalharem em paralelo é a definição da estrutura da API. Com esta definição pronta ambos os times podem trabalhar em paralelo onde o time front-ent desenvolve toda a parte client-side utilizando uma API com dados fictícios enquanto o time de back-end desenvolve a parte servidora se preocupando apenas em respeitar a especificação da API acordada entre as equipes.

Facilidade de inclusão de novos front-ends

Como o lado servidor fornece apenas a API, torna-se muito mais fácil desenvolver novos front-ends para dispositivos específicos como uma aplicação nativa para iOS ou Android, por exemplo.

Os frameworks MVC client-side substituem totalmente os frameworks MVC server-side?

Não. Os frameworks server-side passam a fornecer apenas uma API, normalmente no formato REST, para ser consumida pela aplicação MVC no lado cliente. Toda a parte de controle de rotas, renderização de templates e validação ficam no lado cliente. A parte servidora fica responsável pelas validações (novamente? sim, as validações devem ocorrer tanto no lado cliente quanto no lado servidor) e por armazenar e recuperar os dados em um banco de dados.

Frameworks

Existem diversos frameworks MVC client-side mas alguns que vem ganhando mais destaque ultimamente são:

Alguns outros frameworks que possuem a parte MVC e mais alguns componentes gráficos.

Quais as desvantagens de utilizar MVC client-side?

A principal dificuldade é a necessidade de aprender mais um (ou as vezes mais do que um) framework específico para trabalhar exclusivamente com o front-end. A inclusão dessa parte da aplicação, apesar de facilitar a manutenção como comentado anteriormente, adiciona uma nova camada na aplicação, que precisa ser compreendida e respeitada pelo time. Outro fator importante a ser considerado é o fato de que aplicações client-side necessitam da execução do código javascript para gerarem o conteúdo html e exibi-lo ao usuário. Apesar de praticamente não existirem usuários com javascript desativado em seus navegadores, os mecanismos de busca ainda tem dificuldade em indexar páginas com conteúdo gerado dinamicamente no lado cliente. Se o seu projeto exige que o conteúdo do seu aplicativo seja indexado por mecanismos de busca, talvez adotar uma arquitetura puramente mvc client-side não sejam a melhor opção.

Resolvi fazer esse post de introdução sobre a arquitetura MVC client-side para demonstrar as vantagens deste tipo de aplicação. Em posts futuros vou falar mais sobre o Backbone e como utilizá-lo na construção de aplicações.

eBook Sites

13 de Fevereiro de 2013

English

Português

Aulas Gratuitas

13 de Fevereiro de 2013

Computer Science (English)

Algorithms (English)

Artificial Intelligence | Machine Learning (English)

Computer Vision (English)

Web Development (English)

Scientific Writing (English)

Courses (English)

Algoritmos (Português)

Visão Computacional (Português)

Ciências da Computação (Português)

Matemática (Português)

Diversos (Português)

Metodologia Científica (Português)

Desenvolvimento Web (Português)

Listas

13 de Fevereiro de 2013

Olá pessoal.

A algum tempo eu venho mantendo diversas anotações no Evernote (que é uma ótima ferramenta) com o objetivo de manter as coisas organizadas. Olhando minhas anotações percebi que venho guardando diversas coisas "compiladas" que acredito serem úteis para outras pessoas. Sendo assim, resolvi que vou passar a manter essas listas de coisas como posts no blog, e vou atualizando o mesmo post com o tempo, assim como vinha atualizando o Evernote. Seria bacana se o Everynote tivesse uma função para embutir "notas" assim como existe com o Youtube por exemplo, possibilitando embutir notas em diversos sites mas atualizar em um único lugar. Existe a possibilidade de compartilhar a URL da nota e embutir com iframe, mas não é exatamente o jeito que eu gostaria.

Para começar compartilhei:

Aulas gratuitas para temas relacionados a Ciência da Computação Sites para download de ebooks Sites de buscas para artigos científicos

Estou separando mais listas interessantes e assim que estiverem prontas vou compartilhar.

Até +

Ruby - Diferença entre Blocks, Procs e Lambdas

8 de Fevereiro de 2013

De modo geral blocks, procs e lambdas permitem passar uma porção de código para um método e executar esse código em um momento posterior.

Blocks

Blocks ou blocos é uma porção de código passada para um método utilizando chaves {...} ou do ... end. Por convenção são utilizadas chaves quando o código pode ser expressado em uma única linha e do e end quando o código ocupa várias linhas.

Exemplos usando chaves:


 array = [1,2,3,4,5]
 array.map! { |n| n * n }
 => [1, 4, 9, 16, 25]

Exemplo usando múltiplas linhas


 usuarios = ['Usuário 1', 'Usuário 2', 'Usuário 3']
 usuarios.each do |u| 
     print "Nome do usuário"
     print u
 end

O que possibilita a chamada do código passado no bloco é a palavra reservada yield. Ao usar o yield a execução é desviada para o bloco passado por parâmetro no método atual e o código do bloco é executado. O bloco pode retornar um valor, se isso acontecer esse valor pode ser armazenado e utilizado no restante da execução do método.


 class Teste
     def executar_algumas_vezes(num_vezes)
         @counter = 0
         num_vezes.times do
             print "Interno\n"
             yield(@counter)
             @counter += 1
         end
     end
 end

 teste = Teste.new
 teste.executar_algumas_vezes(3) do |counter|
     print "Executado " + counter.to_s + "\n"
 end

 Execução
 Interno 
 Executado 0
 Interno
 Executado 1
 Interno
 Executado 2

No exemplo acima é possível observar a criação do método "executar_algumas_vezes" que recebe como parâmetro a quantidade de vezes e um bloco. Durante a execução o valor da variável counter é passada para o bloco, que imprime uma mensagem.

Procs

Os blocos são extremamente úteis e utilizados extensivamente porém eles não permitem atribuir o código passado para o método a uma variável. O Proc permite guardar este código em uma variável para poder utilizá-la em dois contextos diferentes sem duplicar o código.


 def multiplicar(valor1)
     return Proc.new { |valor2| valor2 * valor1 } 
 end

 m10 = multiplicar(10)
 m5 = multiplicar(5)

 m10.call(10)  
 => 100

 m5.call(10)
 => 50

Lambdas

Lambdas funcionam de forma semelhante aos Procs com a diferença de que lambdas fazem a verificação do número de argumentos e retornam ArgumentError se não forem condizentes.


 l = lambda { "Lambda!" }
 l.call
 => "Lambda!"
 l.call(10)
 ArgumentError: wrong number of arguments (1 of 0)

Outro ponto importante é que ao encontrar um return os Procs forçam o retorno do método em que estão contidos enquanto Lambdas apenas retornam para o método em que estão contidas que podem continuar a execução normalmente.


 def proc_math
     Proc.new { return 1 + 1 }.call
     return 2 + 2
 end

 def lambda_math
     lambda { return 1 + 1}.call
     return 2 + 2
 end

 proc_math
 => 2
 lambda_math
 => 4

O Ruby 1.9 fornece a opção de criar lambdas com uma sintaxe simplificada utilizando -> Exemplo:


 def chama_lambda(cod)
     cod.call
 end

chama_lambda -> { print "Lambda!" }
=> Lambda!

Até +

Fonte: Tutsplus

Leap Motion Developer Kit

5 de Fevereiro de 2013

Olá pessoal.

Essa semana recebi o kit de desenvolvimento da Leap Motion e resolvi fazer um vídeo para mostrar um pouco do aparelho. A versão que recebi é a 0.5 e não é a versão final, porém de acordo com o site a versão final será a 0.6. Fiquei impressionado com a qualidade do acabamento do dispositivo que é de alumínio e vidro e lembra muito as coisas da Apple. Ainda não tive tempo de ver nada relacionado a desenvolvimento, mas assim que fizer alguma coisa bacana eu faço mais alguns vídeos mostrando.

New blog system using Nodejs, Express, Mongoose, Markdown and Coffeescript

4 de Novembro de 2012

Hi,

After read a few books and blog posts about Nodejs I decided to start a little Blog platform project using Nodejs, Express, Mongoose, Markdown and Coffeescript. The idea was start a project just to learn more about Nodejs ecosystem so don't expect an awesome and organized code :). The project is not finished yet, but it is usable and easy to deploy to Heroku.

The github project is here.

Here some features

  • Use Markdown syntax to write your posts
  • Simple Administration Interface
  • Authentication
  • Search mechanism
  • Contact form
  • Ready to deploy in Heroku
  • Simple 'Projects' area

Upload images and videos in iOS 6 with Safari

1 de Outubro de 2012

With the new iOS 6 we are now able to use File API and HTML Media Capture API to upload images and videos in a web page using Safari.

To see the Demo visit this page using an iOS 6 device

Image Capture and Upload

<input accept="image/*" capture="camera" type="file">

Video Capture and Upload

<input type="file" accept="video/*" capture="camcorder">

Audio Capture and Upload

<input type="file" accept="audio/*" capture="microphone">