微修正が入った Android Studio 3.0 Canary6 ではじめる幽雅?な日常

はじめに

新しいバージョンが出たので再トライ (AS2.3.3だと補完index作成処理で固まる環境で論外なので・・・)

現在 AS3.0 をIDEとして使っていますが、

いつまでgradle plugin 2.3.3で動かせるかわからないので状況を探っている感じ

だったりします。

正直

な感じは同意で大幅な記述切り替えはあんまり遣りたくないんだよなー

  • InstantApp
  • wearApp

はやりたいという要望はあるので、sampleレベルでは試していたりするんですけど HelloWorld以上の壁を超えるのはいつの日か・・

動作環境

  • macOS Sierra
  • 16G
  • HDDタイプのiMac
  • AS 3.0-Canary6
  • gradle plugin 2.3.3
  • gradle plugin 3.0-alpha6
  • gradle runtime-4.1-m1

状況

とりあえず動くようになったので、しばらく試しています

gradle plugin 3.0-alpha5 だと 下記のDSLエラーでチェックが弾かれてました><

library projectはcompile DSL 指定するなや!

compile (':XXXX')

まあ、InstantRunは動かないケースが多いからなー(遠い目

特にdata-binding(APT)使ってると gradle plugin 2.3.3ベースでもよくコケる・・・

依存ライブラリが増えると変な挙動しますし。。

  • dependenciesライブラリのバージョンの不一致

とかが有るらしいんですけどね。まあ既存のjavaでも同じなので(package hell<地獄>)

Java9の package private 辺りが待望されている背景はそこら辺に有るわけですし*1

G様標準形のUIパーツ系は問題ないんだけど、サードパーティのカスタムViewのView属性等が見つからなくてクラッシュ

まあ大分ましになったんでしょうけどね・・


既存挙動

デフォルトだと下記になっていて、パーツ編集する度に補完indexが再作成されて重い状態なのは察しの状態。

databinding reference by editor
  1. 普通のlayout
  2. ConstantLayout
  3. data-bindingを使ったlayout
  4. data-bindingを使ったConstantLayout

の順で加速度的に重くなっていきます*2

でoffってたんですが、Gradle Syncボタンを押してもSyncがいつまでたっても成功しないという・・

buildすれば成功するんですけどね・・。このタイミングって下記のタイミングと同じなんだよなー(遠い目

  • hotchemi 先生の PermissionsDispatcher Plugin

これは挙動の理解不足でした。config.xmlにstringリソースが定義されているとして

  1. main/res/values/config.xml
  2. debug/res/values/config.xml
  3. main/res/values-ja/config.xml

で、debug用のstring_idが main/values-ja で最終的に潰されていたという話

  • NG
main
   res
      values
          config.xml
      values-ja
          config.xml
debug
   res
      values
          config.xml
  • OK
main
   res
      values
          config.xml
      values-ja
          config.xml
debug
   res
      values
          config.xml
      values-ja
          config.xml  //★要追記

新規機能(TLメモ)

ただし新し目のエミュレータのみですね。

因みに自分の環境だと

  • Emuratorの終了時にASごと終了する

んだけどなぜ??

  • 転送時に複数選択できるという話。
  • InstantRun試用していても、InstantRunは自動解除

で最近気になっているのが

  1. InstantRun解除ビルド後
  2. 他の端末(イメージ)を終了
  3. InstantRunビルド再開
  4. 転送時にクラッシュする

一回 下記しないとだめなことも多々・・・。

gradlew clean cleanBuildCache

ビルドの仕方が違う同名のバイナリをリンクしてクラッシュみたいな感じなんですかね(汗


新規挙動(TLメモ)

下記の話、調べたんですが gradle plugin 3.0-alpha6 の問題みたい。

これも同件

現在のところ下記無効にしないと正常に動かないよう

  • gradle.proptiles
org.gradle.configureondemand=false
org.gradle.caching=false

ビルド高速デモとかどうなったんですかね〜(遠い目

まあ複数のスレッド管理みたいなの大変なのは分かるんですけどね・・


現在の開発スタイル・・・

あんまりよろしくないんだよなーとか思いつつ、ビルド中はPC重くて何もできないので・・・

と思ったんですが、職場のWifi環境がセキュリティ強化で超不安定なので意味がなかった><

gradle runtime 4.Xベースから、offline実行をしても

  • 定期的にrepositoryのpom情報をダウンロードしてくる

のでこのタイミングで通信が発生するので、このタイミングでNW不順だと激重になるのは確認してますし・・

な話とかも実は関係あったりするかもな・・・

ASの開発環境って、日本だとあんまり合わない感じなんですかねー(遠い目


気軽に最新pluginをコンパチで試せるbuild.gradle記述の考察

現状は3.0ベースに書き換えるのはマダ厳しいかなと*3

compile/provided DSLが4.X系で廃止? みたいな呟きがあったけど

そこら辺の言及ってstackoverflowあたりしか見つからないんだよな・・・(汗

gradle runtime 5.0ではだいぶ変わる話はスケジュール的に出ているみたいですけど

gradlew tasks 辺りで引っかかる所

apkのファイル名の変更

まずこれがエラーになるので記述を変更する必要があり

旧記述

3.0からの推奨記述

gradle 2.3とコンパチで動かす記述

*app/build.gradle

android {
    applicationVariants.each { variant ->
        if (variant.buildType.name.equals("release")) {
            // releaseビルドのみ、ファイル名にVesionNameとビルド時間を付与
            variant.outputs.each { output ->    //★
                if (output.outputFile != null && output.outputFile.name.endsWith('.apk')) {
                    def versionName = variant.versionName
                    def date = new java.text.SimpleDateFormat("yyyyMMdd_HHmmss").format(new Date())
                    def newName = "apk_v${versionName}_${date}.apk"
                    
                    //=== 修正 ====
                    if (output.hasProperty('outputFileName')) { 
                        output.outputFileName = newName 
                    } 
                    else{ 
                        output.outputFile = new File(output.outputFile.parent, newName) 
                    }
                }
            }
        }
    }
}

ちなみに★はallである必要はない。eachで問題なく動きます

*1:依存解決するよりバイナリサイズ増えても楽な方がいい

*2:富豪環境の方は除く

*3:軽く試してみたけど結構大変。単純にapiとか機械的におき直すだけなら楽ですけど・・