左からの NavigationDrawer が初回に起動する Activity にある場合, 気持ち悪いと思ってましたよね.
あのAndroidの神と言われている Jake Warthon さんが言い切ってます.
アプリにActivity一つで複数のFragmentを使う。ただFragmentのバックスタックは使わない。クソなので。
UI周りでいえば Activity起動時のコストを考えてみれば理にかなってるようにも思えます.
確かに, 「Fragment のバックスタック」周りで混乱する様子はだれもが見てきました。
Reddit でも話題になっており, この意見に同意する人も多い雰囲気.
で, いまどきのストラクチャーでどのような構成にするのか.
Android: the Single Activity, Multiple Fragments pattern | One Activi…
このスライドでは, 画面の数だけ「Presenter + View(Fragment)」のペアを用意する という形の記述となっていますが, Fragmentの特性上これが自然な気がしていますが.
Kotlinのコードががなんとなく見づらいような気がしてましたが.
こんなの公開されています.
このコンテンツについては, GitHubにて公開されていまが,
メンテナーは, Googleにフレームワーク開発において最近合流したあの Jake Warton 神.
android/kotlin-guides: A set of guides for writing Kotlin for Android.
Jake と言えば, ハンガリアン記法についてなどコードスタイルについてはSquare在籍時より強いこだわりを持った発言がありましたよね.
Someone, somewhere made the decision to use hungarian notation for Android Java sources. I think they owe the community an apology.
— Jake Wharton (@JakeWharton) 2014年8月7日
Just Say mNo to Hungarian Notation - Jake Wharton
「Android Kotlin Guides」にはコードスタイルについて記述があります.
例えば, だれもが遭遇していると思われる以下.
When a function signature does not fit on a single line, break each parameter declaration onto its own line. Parameters defined in this format should use a continuation indent (+8). The closing parenthesis ()) and return type are placed on their own line with no additional indent.
関数の記述が一行では収まらないときは, それぞれのパラメータをそれぞれで改行する.それらのパラメータは8のインデントで連続させて, 閉じカッコと戻り型はインデントなしの一行とする.
fun <T> Iterable<T>.joinToString(
separator: CharSequence = ", ",
prefix: CharSequence = "",
postfix: CharSequence = ""
): String {
// …
}
見やすいですね!
これまで, Square から公開していたように, 定義ファイルで公開してほしいですね!
AndroidStudio 3.0 にアップデートしましたが,
こんな build.gradle で 以下のエラーです.
android {
// ...
}
productFlavors {
flavor1 {
// ...
}
}
buildTypes {
release {
// ...
}
debug {
// ...
}
}
Error:All flavors must now belong to a named flavor dimension. Learn more at https://d.android.com/r/tools/flavorDimensions-missing-error-message.html
StackOverflowで調べてみると以下の記述で大丈夫と書かれている.
Android Studio 3.0 Flavor Dimension Issue - Stack Overflow
android {
// ...
flavorDimensions "default" // OK
//flavorDimensions "versionCode" // OK
}
productFlavors {
flavor1 {
// ...
}
}
buildTypes {
release {
// ...
}
debug {
// ...
}
}
これでビルドは通る.
なんだか気持ち悪いし意味が不明すぎますね.
いろいろやってみましたが, 以下のような記述がOKです.
android {
// ...
flavorDimensions "a"
}
productFlavors {
flavor1 {
// ...
}
}
buildTypes {
release {
// ...
}
debug {
// ...
}
}
productFlavor を複数にする.
android {
// ...
flavorDimensions "a"
}
productFlavors {
flavor1 {
// ...
}
flavor2 {
// ...
}
flavor3 {
// ...
}
flavor4 {
// ...
}
}
buildTypes {
release {
// ...
}
debug {
// ...
}
}
flavorDimensions で productFlavor を2段階に分ける.
android {
// ...
flavorDimensions "a", "b"
}
productFlavors {
flavor1 {
dimension "a"
// ...
}
flavor2 {
dimension "a"
// ...
}
flavor3 {
dimension "b"
// ...
}
flavor4 {
dimension "b"
// ...
}
}
buildTypes {
release {
// ...
}
debug {
// ...
}
}
dimension で階層化された Build Variant が作成される.
もともと productFlavor では以下のようなものが設定できました.
- applicationId
- versionCode
- minSdkVersion
- versionName/Suffix
- ソースコードやリソースの位置
- dependencies
これらを階層化させたい場合に使うのがいいように思います.
まずは, 開発時の時間短縮でしょうか.
flavorDimensions "minSdkVersion", "others"