2013年12月12日木曜日

Androidアプリプログラマとして振り返ってみる

Android Advent Calendar 2013 12日目の記事です。

勢いでAdvent Calendarにエントリしたものの、最近新しいことあんまり触ってないし、
ndkでいろいろやっているのですが、記事にするほど自分の中で整理されていません。
前日までのエントリでみなさんとてもおもしろい記事を書いていてどうしたものかと思っております。

ただ、Androidアプリプログラマとしてもう3年以上も立つ訳で、これを機会になにをやってきたかを整理してみたら、
なんだか車輪の再発明的なことをたくさんやってきたような気がします。
ただ、実装しているときにはそれは気がついておらず、後で結果的に車輪の再発明になったものがほとんどでした。

今回はそれについて振り返ってみようかなと思います。

DownloaManagerrの実装

昔ブラウザアプリを作っていたのですが、
その当時Android2.2ではDownloadManagerというものはなく、
自分で実装する必要がありました。

そこで、Link先のMIMEタイプがpdfだったりdocだったりしたら、
Threadをつくり、その中でHTTPのgetでデータを取得し、
OutputFileStreamでデータをファイルに書き出すということをしました。
もちろん、Notificationに進捗率の表示だったり、タップしたらキャンセルを行うという処理もしました。

これが面倒くさかったのは、エラー処理をいろいろしなければいけなくて、
  • SDカードがないとき
  • SDカードが途中で引っこ抜いたとき/マウント解除したとき
  • 通信が途中で切れた時
などなど、例外処理やらif文でエラー処理やらを行わなければなりませんでした。

2sprintなので、だいたい1ヶ月ぐらいの実装でしたが(今考えると結構時間使ったなぁ。)、
最後の最後まで、テストしてエラー処理を追加してを行っていた気がします。

しかし、Android2.3からはDownloadManagerが使えるようになったので、
Android2.3以降はこの実装は使う必要がなくなったわけです。
もっと早くDownloadManagerが使えるようになってればこんな苦労はしなかったのに。。。。

FaceBook型メニュー(Drawer)の実装

Facebook型のメニューは
  • RelativeLayoutにViewを2枚重ねる
  • 左上のメニューボタンを押されたらTranslateAnimationで上のViewを左に移動
  • アニメーションが終わった時点で、View.layout(メニューの幅、0, view.getRight(), view.getBottom())で上のViewを左に余白を作ってlayoutして、requestLayout()
  • closeはその逆
をして実装しました。
(実際はいろいろ細かい小細工をして苦労させられました。。。)

こちらは、AndroidではNavigation Drawerと呼ばれ
今は、DrawerLayoutを使って簡単に実装できます。
http://developer.android.com/training/implementing-navigation/nav-drawer.html

当時はこれ実装するのはすんごく苦労したんですよ。。。

Pull to refreshの実装

あのtwitterアプリでおなじみの引っ張って更新する
pull to refresh。
これも頑張って実装しました。

これは、上のツールバーにViewを隠しておいて、
コンテンツのViewをスクロール可能だったらコンテンツのViewにイベントを流して
スクロールさせ、
スクロールできないところまでスクロールしたら、
今度はイベントをコンテンツの外側のLayoutに渡して、余白のViewをすこしずつ下にさげるという実装だった気がします。
イベントをどこに渡すかどうかの判断はonInterceptTouchEvent()だったかな?
ここら辺の実装はすごく苦労した割にはよく覚えていないのです。

ただこれはいろんあバージョンをつくってためしてみました。
ListViewを使った結滞な実装もありました。

しばらくはこの自作のpull to refreshを使っていたのですが、
あるとき、スクロールがかくかくするというバグが発生し、
そのときボスが見つけてきてくれた
https://github.com/chrisbanes/Android-PullToRefresh/
と置き換えてためしてみることになりました。
今は有名なライブラリですが、当時はあまり使われていなかった気がします。

試して見たところ、実は原因は別のところにあったようで、
動作的にはあまりかわりませんでした。
(実装見てみると、自分が書いたコードとほとんど似たようなものだったので、
当然ですが。)

で、結局オープンソースのライブラリの方が安定していていいだろうということになり、
私が作ったコードは使わないことになってしまいました。
これは悔しい思いもしましたが、
今思い返すと最初からライブラリを探していれば、その工数をべつなことに費やすことができたのでは・・・と思ってしまいます。

まとめ

今は必要で一生懸命実装しても
  • 後々そのコンポーネントが標準で用意されるかもしれない
  • オープンソースでライブラリがあるかもしれない。
ということがあります。

前者は逆に言えば後方互換性をかんがえると実装しておいて損はないと思いますが、後者はオープンソースのライブラリを使用できれば工数を大幅に削減できるはずです。
ちょっと難しいUIを実装する時は、GoogleなりGithubなりつかって、同様なことを実装しているライブラリがないか必ず探すようにしましょう。
最近はAndroidオープンソースライブラリ徹底活用(http://www.amazon.co.jp/dp/4798040029/ref=cm_sw_r_tw_dp_IFYPsb1MYGA62)
やAndroidライブラリ実践活用[厳選111](http://www.amazon.co.jp/dp/4774161284/ref=cm_sw_r_tw_dp_KGYPsb0JBRP63)のような本も出ていますので、手元においておくといいと思います。

ただ、こういった「あのとき苦労したけど、苦労する必要がなかったのでは」的な実装をしても、自分自身では難しい実装を体験することによりスキルアップにつながりました。
今ではちょっと凝ったUIでもそれなりに実装できるようになりました。
もし工数が許すのであれば、自分で実装してしまうのも一つの選択肢かもしれません。自分で実装すれば、その部分のカスタマイズが必要があるときにすぐに対応できるという利点もあります。

結論:頑張って実装したら、その努力そのものは無駄にはならない。


以上、本日のAndroid Advent Calendarに記事でした。
お粗末様でしたm(_ _)m

0 件のコメント: