Flavor Dimensions って何？

productFlavores が超スマートに！

　体験版と有料版でビルド設定を変えたい時などに使用する productFlavors は、実は単純な切り替えだけではなく、設定を変えたい目的ごとに dimension で切り分ける事ができるという事を初めて知った。Flavor Dimensions というらしい。

　例えば、体験版(trial)と有料版(pro)、ベータテスト(beta)と最終リリース(master)でビルド設定を変えたい場合、Flavor Dimensions なしでやると、

productFlavors {
    trialBeta {
        // 体験版向けの設定
        // ベータテスト向けの設定
    }
    trialMaster {
        // 体験版向けの設定
        // 最終リリース向けの設定
    }
    proBeta {
        // 有料版向けの設定
        // ベータテスト向けの設定
    }
    proMaster {
        // 有料版向けの設定
        // 最終リリース向けの設定
    }
}

てな感じで、同じ設定をあちこちにコピペしないといけなくてストレスマッハなのだけど、Flavor Dimensions を使えば、以下のようにフレーバーを目的別に分けて、最低限の記述だけで済むようになる。

// flavor を以下の２つの目的に切り分ける
// 全ての flavor について、どの dimension に属するのか明示が必要
flavorDimensions "appType", "releaseType"

productFlavors {
    // 体験版か有料版かの設定群(appType)
    trial {
        dimension "appType"
        // 体験版向けの設定
    }
    pro {
        dimension "appType"
        // 有料版向けの設定
    }

    // ベータテストか最終リリースかの設定群(releaseType)
    beta {
        dimension "releaseType"
        // ベータテスト向けの設定
    }
    master {
        dimension "releaseType"
        // 最終リリース向けの設定
    }
}

　上記のように設定すると、プロジェクトの Build Variant は "appType" と "releaseType" に属する設定群、さらに buildTypes も掛け合わせて、以下のような構成になる。

• trialBetaDebug
• trialBetaRelease
• trialMasterDebug
• trialMasterRelease
• proBetaDebug
• proBetaRelease
• proMasterDebug
• proMasterRelease

　ビルド設定が倍々に増えて鬱陶しいのは仕方ないけど、最低限の記述だけでよくなったので以前よりは遥かに楽。特にフレーバーごとにソースやリソースを差し変えたい場合、フレーバー名のフォルダで分けて管理せんといかんのがすげえダルイので、そこを極力シンプルにできるのは助かる。

　それはそうと愚痴なんだけど、設定名をキャメルケースで結合されるのって、何と何の組み合わせなのか一目で判別しにくくてイヤなんだよね。trial-beta-debug とかにしてほしい。