Android: Overall and Predictions

Hello, World!

Well. its been a while I'm following what is, in my opinion, the most

interesting happening in the mobile phone arena: the previously rumored as Google Phone, and later officially named Android. The way Google entered on the mobile world was something of unexpected, and, at the same time, filled users, OEMs, carriers and, specially, developers with plenty of expectations.

Some out there might be asking themselves where I've been when Steve Jobs did his wonderful keynote announcing to every corner of the world he’s new engineering achievement: the iPhone. I would like to clarify that it is a great and innovative phone, but in my view, nothing more than that. Remember that, once, upon a time, Motorola RAZR was a great and innovative product...On the other hand, Android has something of renewing to the whole mobile industry. Its is free. It is open. It is completely customizable. And for us, developers, it builds up a entirely new paradigm for developing applications. Application developers or not, many of you might had saw the videos of the first Android SDK, which packages an emulation of what we would see later on a cell phone.

As new SDK releases follows we could preview what later became the first Android phone to hit the market. Many had noticed that the phone has exactly the same software you found on the emulator. Some might say it even looks like the emulator. What I'm trying to say is that was the system as the Open Handset Alliance has made it (Duh!). The HTC engineers had only changed hardware drivers and vuala, there it is! Other OEMs are certainly tweaking their phones so we might expect plentiful of mobile phones for all flavors and tastes to be launched this year (check what Google CEO said @ Telecoms.com).

Yes, Google has rally built something... a really powerful platform... it is even about to show up into the crescent netbook market. What!? Yes, the netbook market. Android has setup fear into dominating Windows XP. Asus, HP, Dell, Acer and recently MSI (checkout @ Engadget) had been spotted attempting to build netbooks over Android. And the latest announced OS update – version 1.5, also known as Cupcake - gives us a hint that this netbook story is becoming serous as it states to support "x86" processor architecture (used by Intel and AMD mobile processors).

Alright so we've made it through here and here it is Cupcake. Cupcake adds lot of news on the platform but if you keep in mind that Android it is being evolved into a community, many of his new features may point clues to what OEMs are planning for they forthcoming mobile devices. I could bet that one of the coming Android phones is an iPhone-like touchscreen phone without a physic QWERTY keypad, as the Cupcake supports virtual keyboard. It’s pretty acceptable that, at least another one of them is a music phone, due to the added AD2P support... (see a full list of changes @ Android.com; see how to emulate the new environment @ Nullwire.com).

The new mobile phone era brings application stores out of the carriers hood - thanks to Apple, I must agree - and just a few clicks away from our fingers, also enabled us to developing innovative applications beyond what we could even imagine. Accelerometer and GPS are now familiar and in the near future will become usual as mp3 players and cameras. Android had moved through it all and added application cooperativeness into the game. Enabled developers to replace untouchable features like phonebook, home screen or even calling applications in the way you just expect from Windows to use a music player, web browser or mailing application as default for all your requests.

Plus, I just could not believe how easy it is to deploy and test applications at Android. And debug it on device! It’s just great! Once you have installed the phone drivers, just plug the phone on the computer; go to Eclipse and press run/debug! That’s all! The application starts running on the phone in a few seconds! Marvelous! For sure, there are new times coming for the mobile devices arena.

Soft Keypad

Orientation Switching

Design Patterns: The Ultimate Reference Site

Hello, world!

As you might have noticed, is quite a while since I did my last post. This crisis times are really tough and even my "posts pruduction" had slown down. That was a joke. Good one, uh? Nevermind. Today I'm here to speak about software design patterns. In fact, I will not precisely speak on them but only point a nice site a friend of mine told me about and which I've been using as reference since then: Source Making Design Patters. This site is really amazing when it comes to this topic! There you may find rapid and straightforward answers to take down your most scareful doubts, or even learn it all to get a nice background on the subject. What the hell are you still doing here? Go for it now!

SCJP 6.0 Exam: Unmystified

Hello, world!

In December/2007, I've just started to study to take my - very late - Java Programmer certification as the version 6.0 of the exam was early released. Although I knew it wasn't the latest version of the exam (and of Java itself), I've started studying for the 5.0 exam, which, alone, has too many new things to be learned for a mobile programmer. This time, I'm going to talk about the Sun Certified Programmer for Java Platform, Standard Edition 6.0 Exam and my experience of doing the test. 

[Offtopic] As you might have noticed, I awoke with the spirit of making things different and, thus, decided to do my first English post here, at MicroKode. I'll probably keep writing my articles this way and I really hope that the few out there who read my daydreams don't bother about it. I also hope this help to transform this "few" in a "little greater few". Now, back to the topic...

As I've said, the 5.0 version of Java has a lot of new things: Generics, Boxing, Enhanced for Loop, Enums, Varargs, Static Imports and Annotations (the last is not required for the exam). So I've just forgot the existence of a newer version - the sixth - and started reading the "SCJP Sun Certified Programmer for Java 6 Study Guide" from Kate Sierra and Bert Bates. This book is just the best. Go for it! 

About one month later I finished reading it and bought the voucher. I gotta say a word on it: the Sun service here in Brazil is just a bunch of crap. They are very polite and try to attend your requests for the best, but I had to wait about 1 month and a half to get my voucher numbers. And when they finally sent it to my e-mail the expiring date was wrong. Luckily I received a new mail with the correct date, before I even notice the other was wrong.

While waiting the voucher numbers I started doing some simulated exam from the Whizlabs software and I, gotta admit, I've never passed the exam in the simulator from these guys. The difficult level they apply on their software is far more hard than the test itself. But, at the time I wasn't aware of this and decided to delay my application to a later date, that turned to be 14th this month, about one year later.

If you think I was studying all this time you are completely nut. I only did the test because my voucher was about to expire! So I stepped to the Prometric site and scheduled my test to January 14th. Note: the current day was January 8th. This day I request a friend to help me with the scheduling and he just ask me why I was applying to 5.0 exam. He argued that the differences between the two versions of the exam where very few and that it won't worth to do the "old" test anymore. I did some searching and found several articles saying the same. Look, I was about to loose 330 bucks anyway, what's the problem on adding a bit more of complexicity to the mix? I took the exam version 6.0.

The "new" Java version hasn't any bigger changes. At least none of the new exam topics were a big deal. Only one class and two new Interfaces to know about. Compared with the wave of changes from the 1.4 to the 1.5 versions, this means nothing. Here are my tips to get passed the test with no headaches:

1. Read the Kate Sierra and Bert Bates book. The reading is soft and the content is great, after finishing it you sure gonna be ready to take the test. Don't forget to make the exercises and re-read the "Two-Minute Drill" a few days before the test, so you can refresh the things in your mind and identify the parts where you have to study a little more. 
2. Buy your voucher as soon as you decide to take the test. Don't wait to finish studying to do so. If you do, you may forget all you've studded before Sun deliver your voucher number.
3. Don't even think taking the test for the 5.0 version. The differences are few to none. I got just one question about Console and none about NavigableSet and NavigableMap interfaces on my exam. Remember your voucher allows you to do any of the exams.
4. Don't even download the Whizlabs exam simulation software. Alright, that's a bit exaggerated. You can download and exercise on it, the software is really good. But keep in mind that the real exam is much easier. When I said "much", I meant MUUUUUUUCH!
5. Don't be afraid, Generics aren't a problem at the exam, but double check Collections. Much of the exam will test your knowledge on declarations, initialization and scooping, flow control and fundamentals. In fact I think about 1/4 of the exam questions just don't compile. There were also two questions about OO (coupling and cohesion), one for IO and a few for Collections and Generics.
6. On the SCJP 6.0 exam, they raised the passing score, but also the test time. And a lot! So, don't run, you got enough time. I finished the test with about one hour and half left.

Finishing the legend, I surprisingly had passed the test... and with easy. Scored 79% when the passing score was only 65%. Obviously I wish I had gone 100%, but I just don't have enough patience to study that much, and, after all, getting certified, alone, was a great deal for me.

Last, but not least, follows a list of test simulators for you to practice on before taking the real test:

Java Incsition, MasterExam, Test Killer and Whizlabs (DON'T PANIC!).

2009: Ano da Invasão Android

Hello, World!

Pois é, depois de mais um mês de pouca - na verdade nenhuma - produção, estou voltando a postar novidades por aqui. Dessa vez vamos falar do "robozinho" do Google: o Android. 

Depois de muita especulação, boatos e afins, finalmente saiu o primeiro celular portador do aclamado sistema operacional do Google... e isso não é novidade nenhuma, afinal, já faz bem mais de um mês que isso ocorreu.  O fato é que isso é apenas o começo... do post.

Nos últimos tempos li muitas matérias sobre o danado do bonequinho verde e ultimamente ele está cada vez mais presente na mídia especializada. Após o lançamento bem sucedido do G1, fruto da parceria entre a tailandesa HTC e a americana T-Mobile, nos U.S.A e, algumas semanas depois, na Europa, as principais forças do mercado de celulares estão correndo atrás de colocar um "robozinho" na rua.

Empresas como a própria HTC, Kogan, Motorola, Sony Ericsson, Kyocera, Asus, Garmin, Huawei, LG, Samsung and Toshiba já anunciaram até datas de lançamento para seus brinquedinhos (previstos, em maioria para o terceiro trimestre deste ano). A danada da latinha verde-limão está sendo cogitada até para substituir o MacOS X, no iPhone! Calma, calma! Isso é apenas um projeto de algum ciêntista/nerd maluco por enquanto. Mas a versão 2.6 do kernel Linux, usada nas entranhas do Android, já habita o gadget dos sonhos da maioria da população do mundial. Jobs que se cuide...

Bom, o que eu quero mesmo dizer com isso é que se você é um desenvolvedor, programador e peão, como eu, e também não sabe implementar um "Hello, World!" em Android, como eu, essa pode ser uma grande chance de oferecer razões concretas para seu chefe não te demitir. Aprenda a mecher nessa jossa! Vou dar uma colher de chá, pode começar vendo os videos abaixo [In English]. Eles são feitos pelos próprios membros da equipe do Android e oferecem o startup legal pra quem não sabe nem do que isso se trata. 

Introduction

Architecture Overview

Application Lifecycle

Android APIs

Building an Application Demo

Depois você pode continuar explorando essa tecnologia aqui e prepare-se! No pior dos casos você poderá participar do próximo Android Developer Challange e faturar uma grana alta, sem contar fama e prestígio. [Talvez eu esteja exagerando só um pouquinho...]

As 10 Características de um Engenheiro Brilhante

Hello World! We're back!

Após outro longo periodo de dormencia, volto à ativa por essas bandas. Estava atarantado com o trabalho e também coisas pessoais (minha filha nasce nos primeiros dias de dezembro e ainda não me mudei). Além do mais, faz um tempo que não acontece nada (ou pelo menos se conteceu passou desapercebido) interessante no mundo mobile. Nada além de resultados financeiros desanimadores para este setor que parecia inabalável. É a crise veio para todos, mas esse tópico vai ficar para um proximo post...

Vim aqui para falar de um artigo que considerei gênial. Um dia desses me fizeram a seguinte pergunta: "Como identificar um engenheiro brilhante?". Complexo. Alguém ai tem a fórmula? O fato é que comecei minhas perquisas de braços dados com o Oráculo e achei o que considerei ser a melhor resposta para a pergunta. 

O artigo com o título: Top 10 Traits of a Rockstar Software Engineer é, em minha opinião uma resposta sensata para a pergunta citada acima. O artigo apresenta uma lista de 10 características que definem um engenheiro brilhante. Seguem minhas experiências e pontos de vista sobre cada um dos aspectos citados no artigo:

1. Loves To Code

Acho que isso se aplica a qualquer coisa que uma pessoa possa fazer. Qualquer tarefa é executada melhor quando há uma pitada de paixão envolvida. Você tem que amar o que faz para poder fazer bem feito. Além do mais codificar não é uma ciência exata. Como dito no artigo: "codificar é uma arte", e toda arte precisa de um pouco de paixão para dar certo.

2. Gets Things Done

Essa é um gancho de direita no queixo desse pessoal que sai da faculdade querendo ser SQE (Software Quality Engineer): "There are plenty of technical people out there who talk about software instead writing it". Como pode uma pessoa descrever como construir software sem nunca ter construído um (projetos de faculdade definitivamente não contam). Bons engenheiros resolvem os problemas de forma simples e objetiva. Vale enfatizar: simples e objetiva. Num software em JavaME, um dos requisitos consiste em salvar as configurações do usuário (aproximadamente 5 bytes) em RMS. O que você acharia se, para esta simples tarefa, um engenheiro levasse 2 semanas e entregasse  6 classes, aplicando nelas inúmeros padrões de projetos? Particularmente achei horrível! “Keep it simple, son”. Mas não entenda esse tópico erroneamente. O processo de análise é muito importante e muitas vezes é necessário muita pesquisa e análise para achar a maneira mais simples de implementar um componente específico, mesmo que ele seja pequeno. 

3. Continuously Refactors Code

"Coding is very much like sculpting". Que mais posso dizer? Se você não sabe fazer refactoring ou se sabe e não aplica no seu dia-a-dia, a probabilidade do seu código não ser dos melhores é alta. Refactoring é uma disciplina que não pode ser ignorada. Li num livro que os projetos de software deviam ser feitos sempre duas vezes. Que apenas depois de observar os erros cometidos da primeira construção, os engenheiros estariam realmente preparados para implementar o projeto "de verdade". Refactoring tem mais ou menos esse conceito: escreva a primeira versão, observe os erros, rescreva e repita o processo até que você acredite que o código está perfeito. Certamente não estará, mas estará bom o suficiente. De quebra você ainda vai descobrir alguns errinhos que você acabou de cometer, e como está com o código fresquinho na cabeça, vai resolve-los em segundos.

4. Uses Design Patterns

"A good engineer always recognizes and leverages patterns, but is not driven by them." Conheça Design Patterns e saiba aplicá-los inteligentemente. Ao contrário do que muita gente pensa, Designs Patterns não devem ser usados em todas as classes que você criar. Apenas use onde é realmente necessário e útil. Dessa vez, ênfase no "útil". Lembra das seis classes e dezenas de padrões aplicados para conseguir salvar 5 bytes no RMS? Muito cuidado com o uso errôneo dos Patterns. Se quando aplicados corretamente soam como verdadeiras obras de arte, quando aplicados de maneira equivocada podem ser grandes vilões, afinal, quem desconfiaria de um todo poderoso Design Pattern? Eu. Na minha curta vida de desenvolvedor, não vi nenhum padrão ser tão reincidentemente mal aplicado quanto o Singleton. Banir esse Pattern  é a solução aconselhada por vários gurus, repetindo uma cruzada semelhante à travada contra o "goto" em 1900 e bolinha. A que ponto chegamos. Portanto, não acredite que padrões de projetos são a solução para tudo. Eles são apenas mais uma ferramenta à disposição e você não vai querer usar uma chave oitavada onde o mais indicado é uma tesoura.

5. Writes Tests

Você não sabe o que isso pode fazer por você e pelo seu software. No final do ano passado minha gerente me deu feedback que eu precisava melhorar minhas habilidades com testes. E ela estava certa. Meus códigos saiam do forno com dezenas de centenas de bugs. E testar é chato. Bom mesmo é escrever código. Então, por que não unir o útil ao agradável e escrever código para testar seu código? Perfeito! No inicio do ano tive de implementar um pequeno banco de dados OO e resolvi aplicar Unit Tests nele. Resultado já faz quase um ano que ele está sendo utilizado, testado e re-testado e apenas 5 manutenções corretivas foram feitas. O primeiro bug só apareceu depois de 3 meses. Nada mal, hein? Fora o benefício de estar muito mais seguro quando minha gerente me perguntou como estava o progresso do desenvolvimento do componente. Eu sabia exatamente onde estavam meus problemas e pude informar com firmeza o andamento do trabalho. Experimente uma vez, e não largue mais.

6. Leverages Existing Code

A chave nesse tópico é: "Não reinvente a roda".  Apóie-se em código que esteja pronto e que já tenha sido provado e aprovado. Procure código pronto no próprio projeto, nos projetos antigos e no google. Se já existe um componente pronto para ser usado, por que escrever um novo e ter que gastar preciosas semanas debugando e testando esse componente? Apenas tenha atenção com as licenças dos componentes que você quiser usar.

7. Focuses on Usability

Essa tarefa nem sempre é fácil. Muitas vezes quem define essas coisas não somos nós, mas sim o pessoal de Marketing e Vendas. Mas faz parte dos ossos do ofício pelo menos avisar quando algo não está lá uma Brastemp. De preferência já sugerindo uma possível alternativa. Por outro lado, se a usabilidade depender apenas de nós, pobres engenheiros, o software, quase que certamente, vai ser um fracasso nesse quesito. Tente delegar essa tarefa aos designers, mesmo que eles sejam completos excêntricos, vão produzir melhor resultado que engenheiros. Certamente o ideal é uma aliança entre os três setores.

8. Writes Maintainable Code

O código fonte tem duas funções básicas: implementar uma funcionalidade corretamente e informar claramente como essa funcionalidade está sendo implementada. Fatalmente, alguém, um dia, terá realizar manutenções nesse pedaço de código que você acabou de escrever.  E esse alguém pode ser você mesmo. Podemos escolher entre tornar isso um martírio ou apenas em mais uma tarefa a cumprir. Comente seu código, siga os padrões de nomenclatura, e nada de escrever código ofuscado. Apenas mantenha em mente que há a possibilidade de você ter de fazer manutenção no seu próprio código daqui a um ano e que, nessa ocasião, não lembrará mais do que fez. Naturalmente o código estará bem documentado e auto-explicativo.  

9. Can Code in Any Language
10. Knows Basic Computer Science

Não tenho o que acrescentar nesses últimos dois tópicos. Você não pode se apegar a uma linguagem, a ponto de não conseguir usar outra. Isso é um erro grave, acima de tudo, profissinalmente.  Tampouco pode se dar ao luxo de não conhecer algorítimos de estruturas de dados, conceitos de banco de dados e paradigmas como liguagens estruturadas ou orientadas a objetos.

Aconselho que confiram o artigo na fonte e aproveitem para lê-lo e extrair alguns pontos os quais não mencionei aqui.