RecyclerViewの上で右クリック。するとサンプルデータの表示が簡単にできる。Viewが重なっているとき、レイアウトエディタでドラッグで制約を追加するのは超困難。コンテキストメニューで制約が追加できるように。ドラッグした対象が重なっている場合、「どのViewに対して」制約を追加するかメニューがでるようになった。コンポーネントツリーでも右クリックで制約を追加できるようになった。ドリルダウンでどんどん選んでいく感じ。panelもデザイン一新。属性の追加が割と簡単にできるようになった。toolsでCSSのプロパティを追加していくのに近い感じ(伝わるかな。よるカスタムディメンションが設定できるようになった。今までは8/16/24といった数値のみだった。ImageView用のサンプルデータにcitiesが追加。ナビゲーションエディタレイアウトにNavHostFragmentを貼り付けたあと、エディタ上でダブルクリックでナビゲーションエディタに飛ぶように。遷移先の画面のFragmentはナビゲーションエディタからぱぱっと作れる。ところで引数を追加できる。これはType-safeになる。Navigation.findNavController(holder.item).navigate(action)}リソースマネージャーAndroidのリソースフォルダは、ユーザー(開発者)のためではなく、どちらかというとOSのための構成になってる。Studio上では単なるファイルなので、中身をいちいち開いて確認しないといけない。3.4でリソースマネージャーが追加された。formatと呼んでた)だったりする。ファイルやフォルダ名をAndroidスタイルに変更するのは苦痛なので、これらをリソースマネージャにドラッグ&ドロップするだけで、空気を読んでインポートしてくれるようになった。インポート時はダイアログが表示され、より細かくインポート時の指定ができる。言語を指定したりとか。今まではSVGのインポートは1つずつしかできなかったが、これもまとめてドラッグ&ドロップでインポートできるようになった。画像リソースをダブルクリックすると、ピクセル密度や言語毎にどれが使われるかが表示される。レイアウトファイルレイアウトXMLもリソースマネージャーで扱ってくれる。同様に、drawableをレイアウトに対してドラッグ&ドロップすると、ImageViewとして追加してくれる。レイアウトインスペクタレイアウトインスペクタ自体はちょっと前に追加されたもので、実行中のレイアウトを見ることができる。Qではインスペクタのための機能が追加されており、いい感じに確認できるように。スタイルで表示されたりとか。今までは属性が全部まとめて表示されていたが、新しいインスペクタでは開発者が設定したものがグループわけされて表示されるようになる。「どれを設定して、どれがデフォルトのままか」が一目瞭然に。今までのレイアウトエディタはスナップショットをとっている感じだったが、新しいインスペクタは「ライブの」データになった。端末側のリストをスクロールすると、インスペクタ側もあわせてスクロールする。新機能として、ビューの階層を3D表示。Xcodeにも同様の機能があったはず。背景色をどのViewが設定してるのかを確認するのにとても役立つ。Studioのために追加されたAPI群。2019youtu.be動画の終盤でTL;DRが出てるけど、「アプリをモジュール使ってrewriteしよう」というセッション。やってAndroidアプリをモジュール化するかがテーマ。モジュール化する?エンジニアが増えてきたとき、お互いの作業をストップさせないようにするため。1つのでかいアプリだと、レイアウトXMLの名前だけみても面倒なことになるが、モジュール化しておけばだいぶ解決するコンパイル速度をあげるため。ビジネス面でもモジュール化は大事。featureとして作っておき、A/Bテストで一部のユーザーにだけ使わせるといった手法がとれる。やってモジュール化するか?切り口は2つ。Feature(機能)とLayer(レイヤー)。'com.android.application'モジュールはAndroidライブラリにする。'com.android.library'そしてベースアプリはmodule1に依存するようにする。featureとして作ることもできる。その場合は次のようにする。'com.android.dynamic-feature'この場合、モジュール側がベースアプリに依存するようにする(この依存が気持ち悪いという意見も)。featureとして用意したmodule2にはアクセスできない点に注意(循環参照になっちゃう)。featureはオンデマンドでのダウンロードもできる。デフォルトではoffなので、apkに含まれる。モジュール間で共通して使いたいコードがある場合は、ベースアプリに持たせるのではなく、coreといった別モジュールを用意しよう。feature(onDemand)にするか?パレートの法則(80:20の法則)にしたがってみるのがよさそう。featureにしてみる。レイヤーボトムアップで考えてみよう。Roomを使うようなデータベースモジュール。Webサービスとの通信とかをやるWebサービスモジュール。それらをまとめたリポジトリモジュール。リポジトリモジュールの上にUIモジュール(図がいるな。apiとimplementationモジュールAがモジュールBに依存している場合。implementation「モックを作る」という言い方のほうがわかりやすいかも。テスト時にモック用実装に差し替えれるよね!既存アプリはどうする?まずはレイヤー化からやってみよう。機能でわけるのはそれから。database扱いは簡単だけど、全モジュールのDBを抱え込むので分離しようという流れに逆行しちゃう。分離はできてるけど、「AとBに同時に書き込みたい」みたいな要求がくるとつらい。DBコネクションもたくさん作っちゃう。ハイブリッドくっつけておきたいものを1つにしておく作戦。柔軟だが柔軟すぎて扱いが難しい。Roomではうまいことマージできないか、改善中。テストの話モジュール化すれば非Androidのモジュール(=テストが早く実行できる)も作れるが、それを目的としてモジュール分けするのは得策ではない(単に難しい)。Robolectricがあるのでそっち使おう。一般的に、依存関係は少なくしよう。いったことも考えよう。「このアプリの構造はすばらしい」というコメントで★5をつけるユーザーはいない。ユーザーをハッピーにするのが一番大事。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。