Não me entendam mal, o aprendizado é interessante e instigante, mas esperava que exigisse menos dedicação para fazer uma aplicação simples.
Boa parte de programar para Android é saber programar a interface de usuário (layouts XML) corretamente. Entre outros materiais estou lendo uma "early edition" do Head First Android Development, que foi cancelado (gosto da abordagem deles). No que se refere aos tais layouts, tem vários trechos assim: "Agora está prontinho, coloque pra rodar!" "Ué, não funcionou, depois de tanto trabalho!!! O que houve???" "Aaah, tem que fazer tal e tal coisa a mais, vamos lá, corrija e tente de novo". Ou seja, tem vários macetezinhos.
Outro exemplo: o thread principal da sua aplicação efetua também operações de atualizar a interface do usuário. Se você chama uma simples caixa de "Loading..." enquanto lê um feed RSS por exemplo, a caixa não aparece, porque a operação de ler o feed, relativamente longa, ocupou o processamento que seria dedicado a atualizar a UI. Temos então que separar o código relativo a interface de usuário (exibir caixa, ocultar caixa) em uma thread e criar outra thread para o código restante, não-UI. Para rodar tudo em sequência determinística, cada coisa em sua thread mas como se fosse uma thread só, o android fornece um método "handler.post(Runnable)" que roda coisas no thread em que foi criado.
Mais um: uma aplicação que não faça nada além de exibir uma lista qualquer. Tem a classe principal, obrigatória para qualquer aplicação. Para a interface de usuário são precisos dois layouts, um para a lista em si e um que representa o layout de cada elemento da lista. Tem ainda uma implementação de Adapter, que é o fornecedor dos dados a serem exibidos. Se os dados vierem de banco de dados (o android tem um SQLite) é preciso mais um ou dois adapters.
Isso que eu nem cheguei na parte de aplicações com mais de uma tela, e da transferência de dados entre uma tela e outra...
