Blog | DClick - Part 3
Blog Android – Injeção de dependência com RoboGuice (Parte 2)
Categorias: Android, Java	Dando continuidade ao post anterior (http://www.dclick.com.br/2012/08/01/android-injecao-de-dependencia-com-roboguice/), neste post eu darei alguns outros exemplos de utilização do RoboGuice, de forma simples. Para a injeção de outras classes, conteudos e valores. Seguem alguns trechos de código que exemplificam a utilização de algumas anotações do RoboGuice:
Android – Injeção de dependência com RoboGuice
Publicado em 1.Ago.2012 por Eduardo Horvath - 4 comentários
Categorias: Oportunidade	A DClick está em fase de expansão e oferece estágio para o cargo de Designer /Arquiteto de Informação, o profissional fará parte da equipe de UX. Pessoas proativas, comprometidas e autodidatas são sempre bem aceitas em qualquer lugar e no time da DClick não é diferente.
- Conhecimentos de Photoshop (Intermediário)
- Estar cursando pelo menos o segundo ano dos cursos Design / Publicidade ou similar.
- Vontade de trabalhar com Arquitetura da Informação
- Algum conhecimento sobre Arquitetura da Informação e Experiência do Usuário
- Ter alguns trabalhos mesmo educacionais desenvolvidos na área de User Interface ou Iconografia.
- Experiência no exterior (viagens pessoais, conferências ou trabalho)
- Inglês (pelo menos leitura).
Foco da vaga
O profissional aprenderá a desenvolver interfaces de aplicações corporativas, sendo elas webapps ou mobileapps, terá amplo aprendizado na área de Arquitetura de Informação onde atuará diretamente com dois arquitetos experientes, auxiliando-os nos protótipos.
O objetivo é formar um profissional capaz de desenvolver wireframes, fluxogramas até chegar a interface da aplicação, sempre acompanhado e orientado por um profissional mais experiente.
Sobre a DClick
A DClick é uma das primeiras empresas Brasileiras inteiramente focada no desenvolvimento do Rich Internet Applications. Com escritórios no Rio de Janeiro e em São Paulo, a DClick possui grandes clientes como Petrobras, Johnson & Johnson, Odebrecht, Mercado Eletrônico, Yahoo entre outros.
Os interessados devem enviar um currículo com portfolio para:
"oportunidade@dclick.com.br" com cópia para:
"eduardo.horvath@dclick.com.br".
Categorias: Guideline, iOS, iPad, iPhone	Sempre esteja preparado para parar
Aplicações iOS param quando as pessoas pressionam o botão Home para abrir um aplicativo diferente ou usam um recurso do dispositivo, como o telefone. Em particular, as pessoas não tocam em um botão para fechar a aplicação ou selecionam Sair em um menu. Para proporcionar uma boa experiência de parada, um aplicativo do iOS deve:
Salvar os dados do usuário o mais rapidamente e sempre o mais razoávelmente possível, pois uma saída ou notificação de término podem aparecer a qualquer momento.
Salvar o estado atual quando parar, no nível mais detalhado possível para que as pessoas não percam o seu contexto quando iniciarem a aplicação novamente. Por exemplo, se seu aplicativo exibe dados de rolagem, salve a posição de rolagem atual.
Nunca Termine Programadamente
Nunca termine uma aplicação de iOS programadamente, porque as pessoas tendem a interpretar isso como uma falha (crash). No entanto, se as circunstâncias externas impedem que o aplicativo funcione como previsto, você precisa informar seus usuários sobre a situação e explicar o que eles podem fazer sobre isso. Dependendo o quão grave o mau funcionamento das aplicações é, você tem duas escolhas.
Exiba uma tela atraente que descreva o problema e sugira uma correção. A tela fornece feedback que tranquilizará os usuários de que não há nada de errado com a sua aplicação. Ela coloca os usuários no controle, deixando-os decidir se querem ou não tomar uma ação corretiva e se continuam a usar o seu aplicativo ou se pressionam o botão Home para abrir um aplicativo diferente.
Se apenas algumas das características de sua aplicação não esta funcionando, ou exiba uma tela ou um alerta quando as pessoas ativarem esse recurso. Exiba o alerta apenas quando as pessoas tentarem acessar o recurso que não está funcionando.
Essa parte é óbvia como quase toda a Guideline do iOS, mas eu vejo a Guideline como um checklist que você deve seguir, porque podemos esquecer dos detalhes, e uma boa experiência é feita pelos detalhes.
Dessa forma é importante ressaltar que a comunicação com o usuário deve ser feita a todo momento, quer seja no momento em que ele usa a aplicação ou mesmo quando não está utilizando. As diversas formas de comunicação são o push, notificações que o usuário recebe quando a aplicação aparentemente está fechada. A notificação durante o uso da aplicação, e porque não, a notificação sobre a instabilidade da aplicação. É muito mais importante e significativo avisar o usuário que a aplicação está sofrendo instabilidades do que esperar que ela dê crash e o usuário sinta esse problema perdendo assim confiança na sua app.
Avisar o usuário é fundamental, quer seja o fato de que sua aplicação não irá rodar muito bem uma determinada versão do iOS, o que é comum, ou que está sobrecarregada e poderá fechar a qualquer o momento. Certa vez eu utilizei o Foursquare e apareceu para mim a informação de que a aplicação estava instável, indicando que eu deveria reiniciar a aplicação pois ela poderia fechar a qualquer momento, e claro, como qualquer usuário eu fui até o limite da aplicação até ela fechar na minha frente. A diferença é que como era um crash previsto não me causou uma experiência ruim, pois parece indicar que a aplicação tem o controle da situação, e que não vou um mero crash por erro no desenvolvimento.
Esse tipo de informação pode definir entre a sua aplicação permanecer ou não no device do usuário, pois alguns dos usuários preferem deletar uma app logo no primeiro crash, por achar que a app não é confiável.
Categorias: Android, Java, Spring, Spring MVC	Dando continuidade à série de desenvolvimento de aplicações REST com Spring, neste post eu darei um exemplo de como realizar PUT e DELETE nas suas aplicaçoes Android com a utilização do Spring.
Caso não tenha visto os posts anteriores, confira em: Desenvolvimento REST com Android, Consumindo JSON com Spring e Realizando POSTs com SpringAndroid.
A seguir, serão demonstradas algumas formas de enviar PUT e DELETE à um servidor, de acordo com o que a função espera receber.
Categorias: iOS, iPad, iPhone	Utilizar Modal nas tarefas ocasionais e simples
Sempre que possível, minimize o número de vezes que as pessoas devem estar em um ambiente restrito para executar uma tarefa ou fornecer uma resposta. Aplicações do iOS devem permitir que as pessoas interajam com as mesmas de maneira não-linear. O uso do Modal impede essa liberdade pela interrupção do fluxo de trabalho das pessoas e força-as a escolher um caminho particular. O uso do Modal e é mais adequado quando:
É fundamental chamar a atenção do usuário.
A tarefa deve ser concluída (ou explicitamente abandonada) para não deixar os dados do usuário em um estado ambíguo.
As pessoas apreciam serem capazes de realizar uma subtarefa autonoma em uma visão modal, pois a mudança de contexto é clara e temporária. Mas se a subtarefa é muito complexa, as pessoas podem perder de vista a tarefa principal que elas suspenderam quando entraram na exibição modal. Isso aumenta o risco quando a exibição é restrita em tela cheia e quando ela inclui vários pontos de vista ou estados subordinados. Continue Lendo
Categorias: Guideline, iOS, iPad, iPhone, Usabilidade	Faça os alvos do tamanho da ponta de um dedo
Categorias: Android, Java, Spring, Spring MVC, Tutorial	Dando continuidade à série de desenvolvimento de aplicações REST com Spring, neste post eu darei um exemplo de como realizar POST nas suas aplicaçoes Android com a utilização do Spring.
Novamente, se você não viu os posts anteriores, eu sugiro que dê uma olhada, eles podem esclarecer possíveis dúvidas (Desenvolvimento REST com Android e Consumindo JSON com Spring ).
Nos exemplos à seguir, eu demonstrarei como realizar dois tipos de POST para um servidor remoto, de acordo com o tipo de parâmetro que ele recebe.