Android 開発初心者, 2017年の開発を振り返る

 
※ この記事は エキサイト Advent Calendar 2017 15 日目の記事です ※

ごあいさつ

はじめまして ウーマンエキサイト エンジニアの伊藤です.

今年 僕は Android 版ウーマンエキサイトアプリの担当となりまして
リニューアルバージョンアップを行うことになりました.

ほかには PHP でサーバー/フロントまわりを浅くやったりしています.
去年は JavaScript で遊んでました.

今回はそんな Android 開発初心者が
リリースにこぎつけるまでに経験したことをお話したいと思います.

できたもの

結果から言いますと
なんとか 5月開発開始 → 7月にリリースをすることができました！

ウーマンの皆さんにはもちろん
メンズのかたがたもぜひインストールしていただいて
毎日の動物占いや記事を楽しんでください.

ちなみに僕は男性で

満月グループごろごろ組の黒ひょう です.

やりたかったこと

今回の開発にあたり 以下の目標を定めました (脳内):

1. ややレガシー気味になっている既存コードを
   モダン(だと思ってる)なものに置き換える
    
2. MVP とか MVVM とかいい感じの設計にしたい
    
3. リアクティブとかいい感じの設計にしたい
    
4. 現在一般となっている Android 開発のやりかたの全体像を掴む
    
5. リリースする (あたりまえ)

開発前の一番楽しい計画段階です.

やったこと

1. もともとのバージョンのコードベースをほぼすべて強行削除

強行削除

このアプリの担当になったときには
もう既に立派なアプリがありました.
(バージョンは 1.2.3 でした)

しかしながら、メンテナンス等の問題があり
コードベースを新しくしたいという思いと
これを機にアプリのコード全体を独裁するために
既存のコードベースをほとんど削除することになりました.

初心者なのにやることだけは暴君

残ったものはビルド設定や
CI, 外部 API 設定くらいとしてしまいました.

(前のバージョンが好きだったかたにはすみません……
しかしながら新バージョンで改良していきたいので
ぜひご意見をください)

2. 他プロジェクトのコードからおいしそうなところを抽出

良くも悪くも真っ白なキャンバスになったので
その上に新たなコードを書ける状態になりました！

次に, エキサイトにあるアプリのプロジェクトは
もちろん Github Enterprise 上で自由に閲覧できるので

開発にあたって

• 他サービスの Android エンジニアのかたに質問
• 片っ端から他 Android プロジェクトのコードリーディング

を行いました.

プロジェクトごとに特色はいろいろありまして:

• MVP な設計 や MVVM な設計
• RxJava を使っていたり
• Realm を使っていたり Android-Orma を使っていたり
• ButterKnife を使っていたり DataBinding を使っていたり

さまざまな特徴があって
コードリーディングしているだけでも
非常に有意義な時間を過ごせました.

今回の開発には相当に他プロジェクトがあってのことで
開発初期の巨人の肩に乗る部分が大きかったです.

最終的に

1. 他プロジェクトで使われているもの
   (多くのプロジェクトで使われているか)
    
2. 自分の力量
   (StackOverflow 力, Qiita 力)
    
3. 簡単にかけるか, 短くかけるか
   (開発期間と初期段階なので早く結果を出したい気持ち)

からライブラリや設計を決定しました.

これはノリノリでライブラリを追加する初期当初の僕のコミットです.

2. 開発

紆余曲折の開発があったので
技術面については後述したいと思います.

3. リリース

開発が終わってしばらくのデバッグのあと
Google Play Developer Console の操作に戦々恐々としつつも
無事リリースができて
今ありがたく皆様にアプリをお使いいただいています.

つかったもの

今回の開発で使っている設計やライブラリのご紹介タイムです。

もし、同じく新たに Android プロジェクトを始める境遇のかた
いらっしゃったら参考になれば幸いです.

MVP な設計を目指す

アーキテクチャは MVP を採用しました.
というのも MVVM が知識不足で不安だったからです……

とはいえ, 他プロジェクトでも MVP を採用したものが多く
十分に枯れたしっかりとした実績があった事実と

DataBinding やリアクティブの知識が求められる MVVM を
初心でいきなり採用するのに
自分の力量に不安なところがあったので
結果的に MVP でもまったく問題なかったと思いました.

とはいえ, 今後別のアプリを開発するとなれば
興味でも技術面でも MVVM を採用してみたいという気持ちがあるので
設計に関しては鋭意見直していきたいと思っています.

しかしながら MVP と主張していても
他のプロジェクトに影響されて
キメラアーキテクチャになっている現在です.

RxJava, EventBus

dependencies {
    implementation 'io.reactivex.rxjava2:rxjava:2.1.1'
    implementation 'io.reactivex.rxjava2:rxandroid:2.0.1'
    implementation 'org.greenrobot:eventbus:3.0.0'
}

この2つは非同期なデータないしイベントを扱うために導入しました.
(EventBus は RxJava だけでも代用できると思います).

RxJava に関していうと
学習コストはヒマラヤのように高いものでした.

(https://pixabay.com/photo-413/)

が, アプリとなるとやはり
スレッド間の操作や UI イベント, ネットワーク処理のような
一筋縄ではいかない非同期処理があるので
多少時間をかけてでも導入することにしました.

採用してみて感じたのは
非常に多くの場面で有用で

コードを書いていて非同期の処理を
同期的にチェーンしていけるのは爽快です.
(JS の Promise に慣れている人は似たものを感じると思います).

API, DB の操作から UI 処理まで
あらゆる非同期処理に活用できたので
プロジェクトには欠かせない存在だと思いました.

Retrofit + Gson + Okhttp

dependencies {
    implementation "com.squareup.retrofit2:retrofit:2.2.0"
    implementation "com.squareup.retrofit2:converter-gson:2.2.0"
    implementation "com.squareup.retrofit2:adapter-rxjava2:2.2.0"
    implementation 'com.squareup.okhttp3:logging-interceptor:3.0.1'
}

REST WebAPI との通信のために導入しました.

Retrofit は RxJava と連携できるので
RxJava を採用したメリットが活きました.

Interceptor よる拡張も簡単にできるので
通信状況を判断して例外を投げたりや
API 共通パラメーターを差し込んだりするのも容易です.

加えて Gson による POJO 変換は
モデルクラスをすっきりとさせて
各レイヤーの結合を疎にしてくれます.
(もちろん Gson 以外も使えます)

Android-Orma

dependencies {
    implementation 'com.github.gfx.android.orma:orma:4.2.5'
    kapt 'com.github.gfx.android.orma:orma-processor:4.2.5'
}

Android-Orma (以下 Orma) は O/R マッパーで
アプリ内 DB でのデータの永続化のために導入しました.

Orma の素晴らしい点は数多くありますが
Orma でも RxJava と楽々使えるので
ここは大きなメリットです.

モデルクラスを定義しておけばよしなに変換してくれて
SQL を意識することがないという
O/R マッパーの利点は開発の容易さに欠かせません.

自分が定義したクラスであっても
タイプアダプタをつくることでシリアライズ/デシリアライズできるので
DB のデータ型に縛られずモデルクラスをドメイン内の型で
わかりやすく記述できるのも大きなメリットだと感じました.

Kotlin

説明は要らないかもしれないですね.
晴れて Android の一級市民となった Kotlin です.

開発開始時にはまだアナウンスされておらず
Java で書いていました.

しかしその後の機能追加時に公式アナウンスされたのを皮切りに
他のプロジェクトでも使い始めたのを見て導入しました.

Kotlin のメリットは数多くあると思いますが:

• 全体的にショートコーディングに向く
• リスト処理, スコープ関数の使いやすさ
• エクステンションによる拡張性
• Java との連携が容易 (JVM のメリット！ 罠もありますが)
• 書いてて楽しい

といったところがあるなと感じました.

Spek

これは導入していないんですが
Kotlin のテストフレームワークの Spek が
BDD っぽくて (※) 使ってみたかったですね.

誰も使っておらずで導入を見送りました…
結局, 安定の JUnit を使っています.

※ 余談で Spek の FAQ では BDD でも TDD でもないようです

Q: Is Spek a BDD or a TDD framework?

Spek in Dutch means Bacon, so you could think of it as a Bacon Driven Development framework. Being serious for a moment though, we (at least the original author) believe that there is a false distinction in frameworks around what TDD or BDD is. Unit tests are ultimately about defining the specifications of your system. As such, Spek is merely a specification framework if it can be called anything. For more information read What BDD has taught me.

Q: Spek って BDD とか TDD のフレームワークなんですか？

Spek はオランダ語でベーコンって意味なので, ベーコン駆動開発のフレームワークとでも思ってくれればいいです. ちょっとマジな話をしますが, 私達 (少なくとも元々の作者)は TDD やら BDD やらはこういうもの, っていうのは間違ったフレームワークの区別だと思っています. ユニットテストっていうのはざっくりいうと, システム仕様を定義することです. とすると, Spek は呼ぶとするなら単なる仕様定義フレームワークということになります. もっと知りたければ BDD が教えてくれたもの を読んでみてください.

その他

• Dagger2
• ButterKnife
• Picasso
• Mockito
• Robolectric

等々…

多くのプロジェクトで使われているものを
使うことができたのかな, と思っています.

反省点

反省点としては他プロジェクトのコードレビューをしていて
実は「あ、よさそう」で設計や技術を変えたりしたので
キメラアーキテクチャになってしまったことや

深く理解せずに使っている部分もあるので
もっとよい使い方や, 正しくなく危ない方法を採用していたりしないかと
不安な部分があるということです.
(特に RxJava, ライフサイクルまわり)

感想

良くも悪くも1人プロジェクトで独裁政権であったので
自由に技術の選定ができたのと
全体を把握することでまんべんなく学習することができ
とても有意義な開発であったと振り返ります.

いろいろ考えると今回のようなワンマン設計/開発では
満足にいかない部分もあると思われるので
ここは今後意識して改善すべきだと思っています.

現在は少し大きめの機能追加を予定して目下開発中です.
一年ちょっとやってみてやっと開発のやりかたがつかめてきた感触がしてきました.

以上, お読みくださりありがとうございました！
勉強会等でお会いする機会がありましたらおきがるにお声がけいただけると嬉しいです.

エキサイト Advent Calendar 2017 はまだまだ続きます.
明日の記事は 「Pythonでの画像処理API」ですね.
楽しみです！