2017年Androidアプリ開発環境

はじめに

あのときどんな思いで開発していたのか、開発環境はどうだったのかなどを記録に残す試みです。

思考

アプリは常に改善し続ける。
リファクタリングは細かく行わないと、地獄を見る。
でもそれが難しいので、せめて開発初期段階からそうならないような作りを心がける。
そのためにライブラリを入れて、共通認識を作ることで開発時の品質低下をある程度防げる（と思ってる）。
学習コストがかかるから今までと同じ方法をとり続けていると成長しない、成長できない。
なので、開発時にある程度の学習コストをかけるべき。
学習コストかけずに秘伝のソースを生産し続けることは悪。
とはいっても、実際の費用と時間次第ではあります。

開発環境

開発機

• MacBook Pro (Sierra)

開発機としてMacは便利です。
仕様確認等でExcel等を開かないといけないときはWindowsもほしくなります。

IDE

• Android Studio 2.3.3
• Android Studio 3.0.1

案件によって使い分けます。
新規のアプリであれば新しい方を使います。

言語

• Java（業務）
• Java, Kotlin（プライベート）

業務でKotlinを採用していない理由は次の通りです。
私の対応業務がJavaを使用する受託の改修案件がほとんどであること。
Kotlinを書いても読める、話し合えるメンバーがいないこと。

プライベートではKotlin使ったり使わなかったりです。
割合は　Java : Kotlin = 8 : 2　くらいです。

アーキテクチャ

基本はMVC、最近はすべてMVVMに移行したい。
イニシャルコスト（人件費、時間）高くなっても、今後の改修に必要なコスト（労力・気力、人件費、時間）を高くするよりマシ。

app/build.gradle

app/build.gradle

def versionMajor  = 0
def versionMinor  = 0
def versionBugFix = 0
def versionBuild  = 1

android {
    defaultConfig {
        versionCode versionMajor * 1000 + versionMinor * 100 + versionBugFix * 10 + versionBuild
        versionName "${versionMajor}.${versionMinor}.${versionBugFix}"
    }

    buildTypes {
        debug {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        staging {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

特筆すべきところ以外は省略しています。
versionCodeとversionNameを個別に更新したくない。
versionCodeの管理を少し楽にしたい。
これをテンプレートにしておくとか、versionCodeの更新をビルドのたびに自動更新にするとかしておくともっと開発が楽になります。
この方法の欠点は、アプリのバージョン1.0.0にする時点でversionCodeが1000になってしまう点。

他にもリリースビルド時に生成するAPKの名前を指定するのも使います。

ライブラリ/サービス

ライブラリの導入は開発速度アップと品質担保、車輪の再発明防止が目的。
ボイラープレート減らしたい。
品質の低いコードを書かれることを防ぎたい。

LeakCanary

https://github.com/square/leakcanary
メモリリークの計測ライブラリ。
必ず導入する。
開発時からメモリリークは計測しておくことで、品質低下を防げる。
計測なくして改善なし。

Crashlytics

https://get.fabric.io
クラッシュログ収集ライブラリ/サービス。
必ず導入したい。
不具合の再現のための調査という作業をかなり減らせる。
また、テストと開発の拠点が物理的に離れすぎているという場合にもかなり有効なはず。
受け入れテスト時のクラッシュとか。
計測なくして改善なし。

Firebaseに吸収されるので早く移行したい。

Gson

https://github.com/google/gson
JSONパースライブラリ。
REST通信がJSONのときは必ず導入したい。
レスポンスをパースしてオブジェクトにできるので楽。
正直、自前でパースしたくない。

DataBinding

https://developer.android.com/topic/libraries/data-binding/index.html?hl=ja
Android標準で使用できるデータとViewを紐づけるライブラリ。
紐づけしていればデータが変更されるとViewも変更される。
画面更新用のロジックをほとんど自前で書かなくていい。
その反面、何かエラーが出るときはDataBindig関係のエラーが大量に出る。
原因が他にあったとしてもDataBindingのエラーで他のエラーが見えなくなることがある。

Retrofit

http://square.github.io/retrofit/
通信ライブラリ。
REST通信するときは必ず導入したい。

Okhttp3

http://square.github.io/okhttp/
通信ライブラリ。
もう通信用クライアントを自前で作りたくない。

RxJava/RxAndroid

https://github.com/ReactiveX/RxAndroid
Reactiveプログラミングをするためのライブラリ。
できるだけ導入したい。
学習コストが比較的高いので、forを置き換えるとかカジュアルに使う感覚でいいと思います。

Dagger2

https://google.github.io/dagger/
DIをするためのライブラリ。
できるだけ導入したい。
学習コストが高いので、カジュアルに使うことは難しいかもしれません。

Picasso

http://square.github.io/picasso/
画像取得ライブラリ。
ネットワーク経由で画像を取得して表示する必要がある場合は必ず導入したい。
画像の取得、キャッシュ等に特化したライブラリで、ネット経由でサムネイルを取得する場合には重宝します。
リサイズ等もできます。

Timber

https://github.com/JakeWharton/timber
ログライブラリ。
導入予定。

さいごに

できるだけ新しい環境に移行しましょう。
受託のお客さんにはそれを推奨していきたい。
いまさら古い環境じゃないとビルドできないプロジェクト渡された時点で修正に必要なコストが半端ない。

たまに古い環境じゃないとビルドできない案件があり、古すぎてそもそも開発機が用意できないことがあります。
古いプロジェクトのまま開発するのは危険であることを理解してもらうことはとても大事だと強く感じるようになった2017年でした。