【剣盾s2】僕が考えた最強のポケモン ユキメノコ、ランクルス、ウインディ

ポケモン剣盾s2が終わったので使ったポケモンエントリです。

剣盾からランクに潜り始めた初心者のポケモンブログに需要はないでしょうが、ポケモン楽しかったし書きたいなあで書いてます。

初心者の例に漏れず、「好きなポケモンで勝ちたい！僕の考えた最強のポケモン！！」でやってて、ひとまずマスボ級に行けてマスボ級下位ですが勝率もぴったり5割とまあ「僕の考えた最強のポケモン！！」の割に満足できなくはない結果だったから書きたいなって感じです。

構築

選出

バカなので基本相手に強そうなポケモンを選出します。

ただ、相手ときちんと殴り合えるスペックがあるポケモンがミロカロスとウインディしかいないので、このうちどちらかは選出に入っていました。

それプラス、ウインディ、ミロカロスが殴り負けそうなら壁が貼れるユキメノコを選出。
ランクルスは受けや催眠パ対策で育成したので（後述）その対象がいればランクルス、モルペコとルカリオは刺さってそうなら選出、といった感じでした。

育成

構築のうち、「僕の考えた最強のポケモン！！」はユキメノコとランクルス、ウインディの3体で、その他の3体はポケモン徹底攻略の育成論などを参考にしました。

ルカリオ
ライバロリさんの動画を参考に、振り方を少し変えた記憶があります。
いじっぱりの耐久寄りの調整です。

ミロカロス
以下の育成論通りの育成です。

モルペコ
以下の育成論通りの育成です。

ユキメノコ
性格：陽気　特性：呪われボディ
持ち物：ひかりの粘土
努力値：H252-D4-S252
実数値：177-100-90-77-91-178
技：ゆきなだれ/みちづれ/ひかりのかべ/リフレクター

使いたかった枠です。ゲンガーと並ぶ最速のみちづれ持ち、かつ数少ないみちづれと両壁を貼れるポケモンということでこの型にしました。
努力値振りは安定して壁を貼るためにHSぶっぱ、特にSはアイアントの種族値を1上回る110なので最速としました。

初めはみちづれできなくても後続のサポートができると言うことで、ゆきなだれの枠を凍える風にしていたのですが、凍える風が有意に役に立ったと言える場面がほとんどなかったのと、呪われボディの影響で確2が取られている技を金縛りしてしまいみちづれを空振ることがあったので、優先度の低い技であり自分より遅い相手には無限にみちづれできるゆきなだれにしました。
みちづれとのシナジー的にも火力的にもこっちに変えた方がよくなったと感じています。

速いので基本的には先発で出しても上からやられることはなかったですが、エースバーンやスカーフ持ちのドリュウズ、サザンドラあたりには上からやられてしまうのでオーロンゲとかと違って壁の保証はされないといった感じ
壁の保証を気にするならそもそもユキメノコを使うな襷もありなのですが、火力が低めの構築で対戦が比較的長めになることが多かったので光の粘土としました。

ランクルス
性格：臆病　特性：マジックガード
持ち物：どくどく玉
努力値：H252-C4-S252
実数値：217-67-95-146-105-90
技：エナジーボール/きあいだま/めいそう/じこさいせい

まさかの最速ランクルス。まさに「僕の考えた最強のポケモン！！」。
最速にすることでSにほとんど振ってないアーマーガアやブラッキーを抜けるのですが、結果的に不要でした。

初心者らしくs1~s2前半あたりで受けが崩せなくて詰まったところで、マジックガードで毒々ややどりぎを無効化できるし好きなポケモンであるランクルスを採用しました。
受けポケや害悪に対抗するため、どくどく玉は催眠ケアです。

選出率は高くなかったですが、こいつがいないとまず負けてたなという試合があったり、催眠前提の構築に対して瞑想6回積んで3タテしてくれたりと入れててよかったです。

技スペは、受けを崩すための積み技である瞑想と自己再生は確定として、残りの2つに最後まで悩みました。
候補としては、かみなり、サイコキネシス、サイコショック、エナジーボール、気合玉等がありますが、そのうちから構築でつらいポケモンに刺さる技をその時々で選んでいました。

最速調整が不要と書いたのは、そもそも最速にした理由であるブラッキーとアーマーガアに対して、最速である理由が失われたからです。
ブラッキーに対しては、あくびが効かずイカサマのダメージも小さいので先手を取れるアドバンテージが薄かったです。ちなみにHぶっぱブラッキーに対してC+2の気合玉が乱数、C+3で確定1発なので、基本的に回復しながら瞑想を積んで気合玉で吹き飛ばすムーブでした。
アーマーガアに対しては、Hぶっぱアーマーガアに対してC+2かみなりで確定1発なのですが、アーマーガア自体ウインディで見れるので結局かみなりは採用しなかったです。
つまり、アーマーガアに対しては選出せず、ブラッキーに対しては先手をとるアドバンテージが少なかったので、最速にする必要性は結果的にあまりなかったと感じています。

ウインディ
性格：無邪気　特性：威嚇
持ち物：弱点保険
努力値：H76-B228-S204
実数値：175-130-129-120-90-155
技：かえんほうしゃ/ワイルドボルト/じゃれつく/おにび

「僕の考えた最強のポケモン！！」感のない普通のポケモンです。耐久振り弱保ウインディです。多分一番活躍したんじゃないかな。

威嚇込みでドリュウズのダイアース（地震）やギャラドスのダイストリーム（滝登り）を確定耐え、バンギラスのダイロック（エッジ）+砂ダメを最高乱数耐えなど結構耐えます。（全て非特化のAぶっぱ前提）
バカなので何意識の調整か忘れてもうた。
Sは最速ドリュウズ抜きでHは16n-1です。

そもそもウインディが弱点とする地面と岩は物理が多く、水に関しても環境で一番多いであろうギャラドスが物理メインであること、威嚇によって元から物理耐久が高いことなどから物理受けに寄せました。
鬼火もあり物理アタッカーにかなり強かった印象です。

最初は両刀にするつもりはなかったのですが、耐久意識の調整なのに対して物理の炎技としてウインディのメインウェポンとなり得るフレアドライブは反動技であり相性がよくないと考え、その他の炎技についても考えたところ結果的に両刀になりました。
耐久があるので場に居座らせたいことが多く能力変化を交代でリセットする誘引が欲しくない、かつ弱保分が無駄になってしまうのでオーバーヒートは採用せず、大文字は命中不安が嫌だったので火炎放射としました。

ワイルドボルトの採用理由は、構築としてギャラが重かったからです。
そもそもギャラがキツい -> よしウインディで見よう！はどうなんだ

最初はじゃれつくの枠を神速にしていたのですが、龍に対して有効な打点がない上にドラパミミに対しては打てないのと、そのままでもそれなりには速く打つ機会が少なかったので変更しました。

AもCも無振りで素の火力は高くなく、弱保が発動する機会も意外と多くなかったですが、そこそこ速い 結構硬い 技範囲が広い なので便利でした。
弱保とダイマで火力を底上げすることができればかなり強かったです。

総論

構築全体として、相手と殴り合えるウインディとミロカロスについては強くはあったのですが、それぞれ勝ち気と弱保と本領を発揮することができる場面が限られており、いつでも強いポケモンがいないのが辛かった印象です。
また、環境に多いポケモンであるロトム に弱く、処理ルートがミロカロスのミラーコート（+火ロトムにはハイドロポンプ）かユキメノコのみちづれくらいしかなく悲鳴を上げながら戦ってました。

ユキメノコが壁を貼れないままやられることは少なかったのですが、裏に積み技を覚えてるポケモンがルカリオしかおらず（あと一応ランクルス）、壁を活かせているとも言いづらかったです。
関連して、構築における基本選出や戦術はなく、相手に合わせた選出で毎回試合をすることになっていたのは改善の余地がありそうだと思います。

個別のポケモンに目を向ければ、活躍してほしいと想定した場面では想定通りの活躍をしてくれたのは良い点でした。
今後は個々のポケモンについてのみではなく構築全体のことを考えながら育成を考えて行けたらいいのかなと思いました。

あとせっかく好きなポケモンでやってるんだからもっとガラルのポケモン使いたい。
ポケモン楽しい。

キルケニーなど

おくれました、すみません。
Beer Advent Calendar、20日目の記事です。

一昨日飲んだRuse Moksaってビールがシナモンがすごくておもしろくてすごいすごかったんですが、アイリッシュビールについて書こうと決めてたのでアイリッシュビールネタです。 

↑Ruse Moksa、僕が少女漫画のイケメンなら「おもしれー女」って言ってるくらい面白いビールでした。50%OFF。

みなさんギネスは好きですか？好きですよね。
クラフトビールとかのうちフルーティーなタイプのビールは好きですか？好きですよね。

ギネスがフルーティーで華やかになったら最高じゃないですか？
あるんですわ、そんなビールが。キルケニーって言うんですけど。

こいつがマジで忘れられない。本当に美味しい。写真が下手なのは申し訳ない
舌が雑なので雑に説明すると良い感じにフルーティで華やかなギネス。

京都の河原町御池あたりにあるダブリンってアイリッシュパブで飲めるんですが、都内で飲めるところを知らないので誰か教えて欲しいでメンス。
アイリッシュパブにそんな行かないのですが、どうやらアイリッシュパブ界隈ではそれなりにメジャーらしいのでいろいろ行ってみたい。

キルケニー最高！ってテンションで日々を生きているのですが、どうやらアイリッシュビールの世界にはまだまだエグい奴がいそうなのでマジで。

雑に見るKoinの内部実装

この間諸用があってKoinの内部実装を見ないと親友のセリヌンティウスが邪智暴虐の王ディオニスに処刑されちゃう運びだったのでKoinをのぞいて見ました。

みなさんのアプリはみなさんの子供です。そこに出どころのわからない謎の物体（オブジェクト）が注入されていると言う事実、耐えられますか？私は耐えられない。どこの男のものかもわからない物体を我が娘に注入するなんて言語道断。どこから注入されているのか探っていきましょう。

雑な概要

本記事の内容はKoinのバージョン2.0.1に関するものです。

タイトルが雑に見るKoinの内部実装なのでまず雑に概要をば。

Koinはアノテーションによるコード生成を行わずにDIを実現しているのですが、中身ではシングルトンなインスタンスに様々を保存しておいて、
by inject()などでそれを引っ張ってくるシンプルな方法でこれを行っています。

ザッツオール！！！！

説明

『Koin物語 再会のミネラルタウン』での主要登場人物は下の7人です。「イカれたメンバーを紹介するぜ！」って感じですね。

登場人物	役割
GlobalContext	シングルトンオブジェクト。KoinApplicationを持ってる。
KoinApplication	Koinを持つ人。
Koin	普通に触ってるとこいつが一番目立つ。Scopeを持つ。
Module	BeanDefinitionを持つ。複数存在することがあり得る。アリエル。
BeanDefinition	大事。Koinでインジェクトするオブジェクトの情報と、そのオブジェクトを生成する関数オブジェクトを持つ。
Scope	BeanRegistryを持つ。
BeanRegistry	全てのModuleが持つBeanDefinitionをまとめて持つ。

いや多いな
さて、イカれたメンバーの紹介も終わったことなので実際にKoinを使用する手順に従って中身を見ていきましょう。

startKoinまで

val myModule = module { 
  single { Controller(get()) } 
} 
startKoin { modules(listOf(myModule)) }

まずはApplicationに書くであろうここです。

まず、module { }についてです。
これModule型のインスタンスを返すトップレベル関数として定義されており、普段中にsingle { Controller(get()) }とか書く部分は、Module.() -> Unit型となっています。
module{ }は内部でModule型のインスタンスを生成し、それに対して各Module.() -> Unitを実行してからこれを返します。
また、single<T> { }はその内部で、返り値となるModuleにTに対応したBeanDefinitionを保存します。

なんかごちゃって来ましたが、つまり、val myModule = module { single { Controller(get()) } }時点でControllerのインスタンスを生成する関数、Controller(get())がこのmyModuleに保存されます。

次にstartKoin { modules(listOf(myModule)) }ですね。
startKoin { }はGlobalContextからKoinApplicationを取り出してそれを返します。

その際に、Koin内のScopeにmodules()に入れたBeanDefinitionを保存します。
また、single(createdAtStart = true) { Foo() }で宣言したインスタンスはこの時に生成されます。

ここまでをまとめると、各インスタンスを生成する() -> TをmyModuleを経由してKoin内に保存します。（詳しく言えばKoin内のScopeのBeanRegistryに保存されます。）

使用する際

ここまででDIする準備は整ったので、あとはこれを取り出すだけですね！

val controller: Controller by inject

では、遅延プロパティ（by lazy）でgetKoin.get<T>()が呼ばれています。
getKoin()では、シングルトンなインスタンスであるGlobalContextからKoinApplication内のKoinを返しています。先のstartKoin { }で様々を保存したヤツを引っ張ってくる訳です。
その後のget<T>()ではScope内のBeanRegistryに保存してある、そのTを返す関数を実行してこれを返します。
singleの場合、そのインスタンスが既に作成されているならそれと同じインスタンスを返します。

フィニッシュ！

まとめ

どうやらみなさんの娘さんに得体の知れない物体を注入してるのはこういった仕組みによるものだったようです。
よく考えてみれば最初に自分で出したもの（Applicationで定義した() -> T）を実行して返してるだけなので、汗が蒸発して巡り巡って飲用水になって帰ってくるみたいな雰囲気でしたね！！！！！

明日はnegito6さんです。お楽しみのかしこまっ！

Yo, Yo, 俺らVector xml手書き部

この記事はAndroid 初心者向け Advent Calendar 2019の15日目の記事として登録させていただいています。寝なければまだ今日なのでセーフです。

プロローグ

さて、みなさんはAndroidアプリのリソースになにを使用していますか？pngですか？pngですよね。そうですよねpngですよね。
（webp？知らない子ですね…）
いやまあpngじゃなくてもいいんですけど、Androidでは、画像リソースとしてpngなどのラスタ形式以外にも、ベクター形式の画像を使用することができます。

Androidでのベクターがなんぞや的なアレはアレです、拡大しても画像が荒くなんなくてxmlで表現できるやつです。
詳しくは以下のあたりをば。

このベクター画像、使うとなにが嬉しいかと言うと、 画像サイズの違うだけの同じ画像を複数用意する必要がないのです。
これによってapkサイズも小さくなりハッピー！だったのですが、でかい画像をベクターでやると初回描画に時間がかかる特性に加えて、今はaab使っちゃえばpngとかでも必要なサイズの画像だけよしなにやってくれるのでもうそこまで嬉しいことはなさそう……（要検証）

そこで「Vector xmlを救いたい」と言う思いの元結成されたのが、我々Vector xml手書き部です。

Vector xmlを手書きする

先ほど、ベクター画像を使う利点は同じ画像を複数用意する必要がないこととそこからのapkファイルの縮小と説明しましたが、もう一つ大きな大きな利点が存在します。

このベクター画像、Android Studio上でxmlファイルを編集することで変更を加えることができるのです。

つまり、画像の色を変えたい、縦横比を変更したいなどの場合に、リソースファイルを新たに用意することなくxmlファイルを編集するだけでこれを済ますことができます。
いやまあすごいことっぽく書いてもxmlファイルって時点で当たり前体操なんですが…

Vector画像のxmlファイルの概要

さて、それでは実際にxmlの画像ファイルを見ていきます。

今回のお題は車両通行止めです。

<!-- ちゃんと全部今回のために手書きしたよ！！ -->
<vector
    android:height="25dp"
    android:viewportHeight="1000"
    android:width="25dp"
    android:viewportWidth="1000"
    xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- 背景の白 -->
    <path
        android:fillColor="@android:color/white"
        android:pathData="M0,0 L1000,0 1000,1000 0,1000"/>

    <!-- 赤い円 -->
    <path
        android:fillColor="@color/hyousikiRed"
        android:pathData="M0,500 A500,500 0,1,0 500,0 A500,500 0,0,0 0,500"/>

    <!--白い線-->
    <path
        android:strokeColor="@android:color/white"
        android:strokeWidth="24"
        android:pathData="M48,500 A452,452 0,1,0 500,48 A452,452 0,0,0 48,500"/>

    <!--中の白い円-->
    <path
        android:fillColor="@android:color/white"
        android:pathData="M192,500 A308,308 0,1,0 500,192 A308,308 0,0,0 192,500"/>

    <!--赤い斜線-->
    <path
        android:strokeColor="@color/hyousikiRed"
        android:strokeWidth="192"
        android:pathData="M0,0 L1000,1000"
        android:trimPathStart="0.2"
        android:trimPathEnd="0.8"/>

</vector>

意外と読めますね。 <path />のタグが一本の線とそれに囲まれた図形を表しており、それらを重ねることでパス図形を表現しています。
<path />内の要素はここに使われてる以外にもいろいろあり、それぞれ以下の感じです。

要素	意味
strokeColor	線の色
strokeWidth	線の太さ（px指定）
strokeAlpha	線の透明度
strokeLineCap	線端の形状。enum値で指定。ここでも見てくれ
strokeLineJoin	線結合部の形状。enum値で指定。ここでも見てくれ
strokeMiterLimit	説明が難しいのでここでも見てくれ
fillColor	囲まれた範囲の色
fillAlpha	囲まれた範囲の透明度
fillType	説明が難しいのでここを見てくれ
trimPathStart	始点をパスの途中の位置に設定できる。0~1で指定
trimPathEnd	終点をパスの途中の位置に設定できる。0~1で指定
trimPathOffset	トリムする位置をずらせる。0~1で指定

※trim系は特に0.5超えた時の挙動が死ぬほど言葉で説明しづらいので試してみることを推奨します。（正直よくわかってない）
世界一便利な表を作ってしまいましたね。ただのリンク集だけど

勘の良い読者ならもう気づいているでしょうが（言ってみたかった）、これはxmlの皮を被ったsvgです。（名探偵コナン）（筆者はsvgが全くわからない）（野生の馬）

上の表で唯一説明していないpathDataこそがこのパスの本体となっています。
svgの記法で書かれてるのでその記法について詳しくはここを見てくれ！

pathDataの説明

リンク集やってても仕方ないし読んでる人的にもなにが言いたいんじゃだと思うので上の止まれ標識を挙げて実際に説明していきましょう。

まず、簡単な説明として、ここのpathData、または元となったSVGのdはいくつかのコマンドにより線（パス）を表し、そこで囲まれた図形（パス図形）とパス自身によってグラフィックを表現します。
とりあえずそれだけ頭に入れてヒャウィゴ！

親要素

まず親要素のコイツについてはなんかまあ見たまんまです。

<vector
    android:height="25dp"
    android:viewportHeight="1000"
    android:width="25dp"
    android:viewportWidth="1000"
    xmlns:android="http://schemas.android.com/apk/res/android">

唯一ちょっと見慣れないviewPortなんとかはpxで表現された画像サイズを表します。

背景の四角

<!-- 背景の白 -->
<path
    android:fillColor="@android:color/white"
    android:pathData="M0,0 L1000,0 1000,1000 0,1000"/>

pathDataで示された範囲内に白を塗ってます。

pathData内では、M0,0で(0,0)の座標に始点を設定、L1000,0 1000,1000 0,1000 で始点から(1000,0), (1000,1000), (0,1000)の順に直線を引いて四角形を表現しています。
ここで使われたコマンドをまとめると、始点を指定するMコマンドと、現在の点から与えられた点へと直線を描くLコマンドです。Lコマンドに複数の座標を与えることで、その順に直線を描いています。

そうあと激アツポイントなんですけど@colorとかが参照できます。

円

円については今回3つの要素で描かれています。
赤い円、白い線、中の白い円の3つですね。

これらに使われているコマンドは先ほどの始点を指定するM以外ではAだけです。
一番大きな赤い円で見てみましょう。

<!-- 赤い円 -->
<path
    android:fillColor="@color/hyousikiRed"
    android:pathData="M0,500 A500,500 0,1,0 500,0 A500,500 0,0,0 0,500"/>

まず、Mコマンドで(0, 500)に始点を指定しています。
その後にはA500,500 0,1,0 500,0が続きます。

Aは弧を描画するコマンドであり、
これは、A(X方向の半径)(Y方向の半径) (円をどれだけ回転させるか),(描く弧が長弧なら1、短弧なら0のフラグ),(弧の向きの0,1フラグ) (終点座標)で表されます。

このままだと円の一部が切り取られており、綺麗な円になっていないので、この終点から、最初に指定した座標までもう一つAを使って弧を描いています。

赤い斜線

<!--赤い斜線-->
<path
    android:strokeColor="@color/hyousikiRed"
    android:strokeWidth="192"
    android:pathData="M0,0 L1000,1000"
    android:trimPathStart="0.2"
    android:trimPathEnd="0.8"/>

この子はそれほど難しくありませんね！
左上から右下までMとLを使って線を引き、二つのtrimPathほげほげで線の始点と終点を調整しています。

まとめ

どうです？意外と書けそうってなりません！？

まとめとか書いときながら特にまとめることもないのですが、まあxmlで画像やると手書きできるメリットがあるよって話でした。
Android Studioのxml画像のプレビューが変更から一瞬で反映されるので体験としても悪くはないかと思います。

Android 初心者向け Advent Calendar 2019、明日（今日）は@aosa4054さん、よろしくお願いします。僕なんですけどね。 それではまた明日もお会いしましょう。

参考

なんかSVGのpathをめっちゃ説明してくれてるサイト

ここに限らず、調べながら手書きするならSVGで検索することを強くおすすめします。

いろんなbibファイルを一つにマージする

弊学の図書館サイトではbibファイルがダウンロードできるのですが，texファイルから参考文献参照するのに一つのbibファイルにまとめたくて，でも全部手でコピペして一つのファイルに書き足していくのが面倒だったので喰らえ！俺のワンライナー！

歪んだ育ち方をしてきたのでワンライナー以外のシェルの書き方を知らない

— あおさ (@aosa4054) 2019年11月29日

for bib in $(ls references | grep .bib$);do path="references/$bib";key=`echo $bib | sed 's/\.bib//'`;cat $path | sed -e "/^abstract/d" -e "s/^\(@.*\){.*\,/\1{$key,/" -e "s/\_/\\\\_/g"; done | awk '{print}{system("")}' > references.bib

forを使ってる時点でワンライナーじゃねえ
referencesディレクトリにbib全部突っ込んでこれで一つのファイルにまとまるね，keyはファイル名だしわかりやすいね．めでたしめでたし．

※当方TeXドシロにつき，これじゃ〇〇のとき使えねえじゃんとかあると思いますが優しくしてクレメンス

[お気持ち] Androidアプリのデザインは組み合わせ最適化の問題ではなく解釈の問題だと2019年末頃の僕は思っていました。

前回、[お気持ち] Androidアプリでtoolbarって気軽に置くものじゃない気がしてきた - ハヤシライスに入ってるマッシュルームが好きに続いてデザインへのお気持ちエントリです。
デザイン無知無知マンの僕がイキり散らすので不快だったらごめんなさい。

個人でアプリを作った経験から、アプリのデザインを考えたことがあるのですが、そこで思うことがあったのでそのことについてです。

今までやってたこと

今までの僕は必要な機能に対して、一対一のような感覚で適当なMaterial Componentを割り当てて、それを組み合わせるようにしてデザインを作っていました。

例えば、ユーザーに一番やってほしい機能にFABを割り当てて、切り替えたいリストがあったらViewPager、リストの各アイテムのデザインはうんうん言いながら横並びの適当なデザインをする、もしくは、このコンポーネント使ったら便利じゃね？みたいな感じなど、言わばコンポーネントに軸を置いたデザインをしていました。

ただ、なんかダサいなといった感覚や、Material Studies、既存の良さそうなアプリに対して味気のなさすぎるデザインだという感覚を常に感じていました。

気づいたこと

そこで色々見てて思ったことは、タイトル通り、これは組み合わせ最適化の問題ではなく解釈の問題だなということです。
なんか言いたいことがうまくまとめられる気がしないのですが、デザインのフローを
🙅‍♂️成し遂げたいこと -> 必要な機能 -> コンポーネントに割り当て -> 組み合わせ
🙆‍♀️成し遂げたいこと -> その表現としてのデザイン
に変えようと思いました。

このように考えるようになってから、Androidの人ならみんな大好きであろうマテリアルデザインについても勘違いをしていたのかなと思うようになりました。

DroidKaigiのこのセッション、ものすごく面白くて超好きなのですが、この中でもコンポーネントの話が出てなかったのがすごい印象的で、つまり僕がこのセッションと経験から感じたことは、Material Guidelinesは考え方のガイドラインであって、Material Componentsを組み合わせたらいい感じになるよ！ではないのだなということです。（当たり前体操）

Material guidelinesの考え方がさき、Material Componentsはあと

— あおさ (@aosa4054) November 12, 2019

（Material Studiesも結構コンポーネントをカスタマイズしてるんですよね）

お気持ち

最高のアプリを作りたいのでもちろんデザインも最高にしたい……

ここに書いたことが正解だ！お前ら読め！オラ！これが真理だ！みたいなつもりはないですが、少なくとも現時点でこうだと思ってることでした。

[お気持ち] Androidアプリでtoolbarって気軽に置くものじゃない気がしてきた

タイトルの通りです。
Android StudioでNew ProjectしてEmpty Activityを選んでもtoolbarはついてきます。Emptyじゃないじゃん。

そんな印象が関係しているかどうかはわかんないですが、個人でアプリ作る時にも僕は割とまずtoolbarを置いて、そこからコンテンツどうするか、みたいに考えてた気がします。
ただ、特に下タブを採用している場合は（理由は後述します）toolbarは気軽に置くものじゃない気がしてきたなあって日記です。

toolbarってなんなん

まずなんですけど、toolbarってなんなんってなって大正義Material GuidelinesのApp bars: topのページをを見たら、

The top app bar provides content and actions related to the current screen. It’s used for branding, screen titles, navigation, and actions.

It can transform into a contextual action bar.

って書いてありました。*1
つまり、toolbarの役割は開いている画面に関連したコンテンツの表示や操作で、toolbarを置く目的はブランディング、画面タイトルの表示、遷移のナビゲーション、操作って感じですね。
操作 (Actions)ってわかりづらいですけど、toolbarに検索ボタンとかハンバーガーとかあるあれですよな。

なんで気軽に置くものじゃない気がしてきたか

上でなんか出したtoolbarを置く4つの目的、

• ブランディング
• 画面タイトルの表示
• 遷移のナビゲーション
• 操作

のうち、 操作 ってそもそもtoolbarに置いてる必要がなくないですか。

エアビだと検索の操作はtoolbar内じゃなくて独立して置かれてるし、
Abemaでは操作は下appBarに置かれてる

toolbarに検索アイコンだけ置くより、エアビのやり方の方が親切でわかりやすいですし、アベマのやり方の方が操作しやすい、だからこそ、toolbarに検索アイコンだけ置くより、エアビのやり方の方が親切でわかりやすいですし、アベマのやり方の方が操作しやすい。（小泉構文）

つまり何が言いたいかと言うと、なんらかの操作をユーザーにして欲しくて、それをtoolbarに置こうとしている時、基本的にもっといい方法があることが多いんじゃないかって思いました。
ただ、toolbarが既に置いてある、または他の条件によってtoolbarを置くのがベターな場合はtoolbarに一緒に置くかあってぐらいの選択肢な気がします。

次にナビゲーションについてですが、戻るボタンとか閉じるボタンとかのあれですね。
これはあって悪いことはない気がします。ただ、操作のとこで書いたのと同じで、これのためにtoolbarを置くのはぐぬぬくないですか？
toolbar使わずに左上にナビゲーションのボタン置くだけだったり、スクロールできる感じの画面ならappBarLayoutでなんかいい感じにしたりの方がよくないですか？

そして、画面タイトルの表示ですが、toolbarに「検索」とか「通知」とか書いてあるやつですね。
これ自体はあって悪いことはないと思うのですが、最初に 特に下タブを採用している場合 って書いた理由なんですが、下タブにラベルを貼ってユーザーが既にその画面のタイトルや役割を知っている場合って、これいらなくないですかと思いましたのですまる

toolbarを置く理由

なんかここまで見返すとtoolbarガチアンチっぽいですが、置く理由もちゃんとあると思います。

具体的には

• 画面タイトルをtoolbarで示したい場合（下タブんいラベルが貼ってあるなどしていない場合）
• ブランディング

の二点が、toolbarを置くのを考慮しうる理由だと僕は思います。

やっぱりtoolbarにお洒落なロゴあったりするとブランディング的にいいんじゃないかなって思いますし、ユーザーが今開いてるのがなんの画面かわからないって状況は避けたいものです。
こう言った理由から、toolbarを置くぞ！ってなってかつ、画面のナビゲーションや操作も置きたいなってなった場合のみ、それらの要素をtoolbarに埋め込む選択肢が出てくるんじゃないかと思いました。

toolbarについての総評

基本的に僕は個人のアプリにはtoolbarを置きたくないマンなのでなんかやっぱりガチアンチっぽくなっても歌。

と言うのも、僕みたいなデザインなんもわからんマンからすると、アプリの一番上の目立つところに単色のバーを置いてしまうと、デザインがやりづらくなってしまうんですよね。
あと、シンプルにユーザーから見えるコンテンツの縦の長さが短くなるのであんまり置きたくないなあと。

いや、なんかわからんけど！個人アプリとかで！脳死で置くのは！やめようと！思いました！アデュー！

*1: