年も変わってしまいましたが2015年の振り返りなどやってみます。
始めてAndroidエンジニアとして参加したプロジェクトがクローズ(というか開発なし現状維持運用)して、別のプロジェクトに移った。Androidやりたいよーって言ってたらWebフロントエンドで配属された。まったく納得できなかったけど、いろいろあって数ヶ月でAndroid開発に戻ったのでまあ良かったかな、という感じ。
とはいえ、数ヶ月だけやっていたWebフロントエンド作業の中でReactとかElectronとか最近流行りの技術に触れ、個人プロダクトのOmnitweety for Chromeに還元したりできたので結果的に良かったとは思う。あと静的サイトジェネレータ系検討してる人、Hexoだけは使うなよ、絶対だ。
毎年OSS活動したいなーとか個人でもアプリ開発したいなー、とか思いながら活動できてなかったんだけど、今年はいろいろできたと思う。全体的なGithubでのアクティビティはこちらで確認してもらうとして、主だったところは下記三点
Omnitweety for Chrome
ChromeのOmniboxからツイート・URLをシェアできるツイート専用Twitterクライアント。ブログエントリはこちら
画像検索してファボるやつ
FabricのTwitter Kitを試してみたくて作ったAndroidアプリ。画像を検索してひたすらファボるアプリ欲しかった、というのもある。ブログエントリはこちら
Omnitweety for Android
初めて個人でGooglePlayに公開したアプリ。名前からわかるようにOmnitweety for ChromeをAndroidに移植したような機能。ブラウザからURLをTwitterに共有することに特化している。おかげ様で国内外のいろいろなブログで紹介してもらえて、結構テンション上がりました。ありがとうございます。ブログエントリはこちら
個人で開発してると、業務で使ってないライブラリやデザインパターン試せて、いろいろ知見たまってよい。作ったものをGithubで公開して星集まると承認欲求満たされるし
iOS/Androidで使えるSQLiteの代替DB。
Android版はこの一年で非同期クエリが使えるようになったりRxJavaがサポートされたり、かなり使いやすくなってきている。
ここ半年くらいGithubのissueをwatchしてるんだけど、Realmのチームは上がってきたissueに対するサポートが厚くて、ホントすごいと思う。ちょっと調べればわかるじゃん？って質問とかこれむしろRealmじゃなくてAndroidフレームワークに関する質問じゃん…ってissueにも丁寧に(そして迅速に)コメント返してる。
今後もスレッド間通信の件とかRobolectricのサポートとかいろいろ機能追加が待ってそうなので、引き続きwatchしつつ活用していこうと思う。
リスト操作とか非同期処理がいい感じに書けるやつ。
いろいろなオペレータがあってどれを使ったらいいかわからなくなりがちだけど、公式にチャート的なやつが用意してあるので、それ見ると大体やりたいことに合ったオペレータが見つかることを9月くらいに知って、それからは map や flatMap 以外のオペレータも使えるようになってきた。
とはいえまだまだ知らないオペレータばかりなのでいろいろ書きつつ試していきたい。
DIライブラリ。
Componentの書き方はベストプラクティスが掴みきれてないけど、最近はApplicationレベルのComponentを一つとActivity毎にComponentを一つ作る形に落ち着いている。ViewやFragmentにはActivityのComponentから依存関係を注入している。
ただ、後述するMVPアーキテクチャを採用したアプリだと、このComponentの分割方法だとConfiguration ChangeでPresenterが再生成されてしまう、という課題がある。今年はこの辺りのうまいやり方も模索しようと考えている。
Viewからロジックを分離しよう、時代はMVP/MVVMだ！ という記事を結構見かけた一年だったように感じる(私のアーキテクチャ系トピックに関する情報感度が上がってるだけかもしれないけど)。Androidの標準ライブラリとしてDataBindingが追加されたのも大きいんだろう。
Omnitweety for AndroidはClean Architectureで実装してみて、なかなかメンテのしやすいコードになったんじゃないかなー、と自負している。
これはMVPと言うよりはClean Architectureのメリットだけど、Modelにあたる部分がデータ取得・保存クラスとドメインロジックを適用するユースケースクラスに分かれてて、かつユースケースクラスはその名の通りそれぞれ一つのユースケースロジックを実装しているだけなので、機能追加や修正時に他のユースケースに与える影響が非常に少なくすむ。
ただ、ユースケースの数だけクラスが増えるので全体的なメソッド数は膨れ上がるしboilerplateなコードも増えるので、そのまんま適用するんじゃなくてうまい落とし所を見つけたい。
MVPはViewがシンプルになってとてもいいです。 MVP過激派はPresenterにAndroid固有クラス持ち込むな！っていうけどRobolectricあるし、Bundleとか入るくらいならいいんかなーって最近は思ってます。
Android固有のクラスを持ち込まない、となると必然的にView側にある程度ロジック残っちゃうのでどう処理するのがいいんだろう…っていうのが最近の懸案事項。あとResourcesどうしたらいいの。getString()とか…
いい加減まじめに書く。MVPだと単体テストしやすいので、Robolectricも使っていい感じに。
xmlにロジック書くのもあれだし、かと言ってButterKnifeの代替としてだけ使うのはもったいないし…
今年はKotlinでアプリ書くぞ
二本くらいリリースする
今年もよろしくお願いします。