TODO Android 5.0 Lolipop対応のコードも書いていかないといけない

プログレスダイアログ

STYLE_SPINNER

// TestActivityにダイアログを表示します
ProgressDialog dialog = new ProgressDialog(TestActivity.this);
dialog.setTitle("dialog test");
dialog.setMessage("処理中");
dialog.setProgressStyle(ProgressDialog.STYLE_SPINNER);
dialog.setMax(10);
dialog.setCancelable(false);
dialog.show();

// イベント後などに設置して、dialogを殺します
dialog.dismiss();

よくアプリで多いのが、このローディング系のプログレスダイアログ。
setCancelabeleをtrueにすれば、ユーザがタップすれば消えます。また、setMaxで指定した値を使って%表示にしたり、ダウンロードカウントを設定することも可能です。
HOLIZONTALというものもあります。こちらは、クエストのダウンロードがあるゲームアプリなどに最適だと思います。

static

通常、Javaのソースを書くときにあまりstaticなものは作りません。作るとしたら、それこそ、ヘルパーかフレームワークの作り的にそうならざるを得ない場合でしょうか。
ですが、instanceを生成するごとに処理時間がかかってしまうのが実情です。近来では処理速度自体が向上しているので、さほど気にする必要はないのかもしれませんが、スマフォアプリの場合は別でしょう。少しでも処理コストを下げることがユーザをつかむためには必要だと思います。

static void sample() {
   // 静的な処理
}

// このようにnewすることなく、いきなり使えます。
// Helperなどにしてどんどんstaticなものを増やしましょう。
// ただし、staticにするかどうかをしっかりと考えてやるのは言うまでもありません。
// 判断できないのであれば、effectivejavaなどを読むといいと思います。
sample();

同期

同期することによって、便利なスケーラブルなアプリを作ることができます。Webサービスと連携することがいい例でしょう。
ですが、その便利さの反面、電池の消耗が激しくなったり、電波が悪い場所ではアプリ自体が動かなくなったりとフルネイティブアプリに比べるとどうしてもまだ不完全な気がします。
これの対処法ですが、全てをリアルタイム処理しなければいいのです。要は、同期するという処理を全体的に及ばせるのではなく、ユーザのアクションAに応じて同期、ユーザのアクションBに応じて同期しない、という実装に変えてやる必要があります。
同期自体は、とあるイベントですればいいでしょう。クラウドへの保存や、ユーザのDB情報が変わるレベルの挙動でのみ同期したらいいのではないかと思います。常に同期を取っていては、電池の消耗は激しくなってしまい、ユーザが離れる原因となってしまう気がします。

ポ◯モンゲットだぜ！

某有名プログラマ記事を読んだ方はわかるかもしれません(´∀｀)
要は、例外を全て捕まえて、ログハイてから、噛み殺せということですね。

try {
    // 何か不具合が出るかもしれない処理です。
} catch (Exception e) {
    // 全てをゲットします。そして、吐き捨てます。
}

私達は人間なので、全てにおいて完璧なソースを書くことができません。それを承知のうえで。ちゃんと描いてますが、もしものときのために我々は、例外処理を書くのです。

C

最初は、Android書く時に私が感じたことですが、えー、Javaで書くのかよ、大丈夫かそんなんで、と思っていました。
その時に2.3ぐらいの時でしょうか。Cコードが使えるという情報を得、Androidに興味を持ちました。
しかーし、Cで作るわけではなかった。
あたりまえですが、端的に言ってしまえば、Javaで書くところを、Cで処理を高速化できるだけです。
画像とか動画処理には有効かもしれませんが、基本的には微妙なところです。それこそ、ゲーム系などのアプリには有効でしょう。なぜなら、Cコードを入れるということはその分、容量が増えるという可能性もあるので、元々でかいゲームにはそれよりも処理効率を優先したいはずです。ただ、テストが大変かもしれません(・_・;)

機能美<パフォーマンス

やっぱり、ユーザからして使いにくいアプリなんて速攻削除の対象です。当然
その一番の理由になりやすいのが電池の消耗でしょうか。次に使いにくいとか、ださいとかはやってないとか理由はいくつかでてきますね。
電池の消耗に関してはどうすればいいのか。ユーザが見て、電池の消耗が激しいとか思われなければいいのです。例えば、電池が充電されてる場合、8割以上電池が残っている場合、wifiにつないでる場合にデータ通信を大量に行うようにするとか。push機能は私も必ず実装しますが、GCMで、ユーザのアクション時にデータ通信を大量に行う。通信エラーを捕まえた時、向こう30分はこっちからデータ通信を行わないなどの処理を入れる。