今更「dp」について考える
この記事は 飲酒プログラミング Advent Calendar の15日目の記事です。
どーも。どくぴーです。
会社の方で、デザイナーの方に「dpがよくわからない…、というかAndroidって画面サイズバラバラだけどiPhone SE（1st gen）みたいな小さい画面みたいな考えってあるんですか？」という質問を頂き、せっかくなので今更dpを考え直してみようと思いました。 これはスライドの要点の書き起こしであり、スライドだけを見れば十分な場合が多そうです。
導入
僕が仕事をする上で、デザイナーさんがiOSアプリのデザインをされている時に「小さい画面のデザイン」というと、横幅320pxの画面に対するデザインのことだと考えています。ではAndroidではどうでしょうか。
物理的に小さいデバイス…、って言うと。最近だと楽天モバイルで販売されているRakuten Miniがありますよね。ほかにも小さいデバイスなんていっぱいありました。でもそれはデザイナーの方が言うところの「小さい端末」でしょうか？という話です。
dpとは？
Androidの画面デザインでは、昔から dp を用いています。これはdensity-independent pixels（密度非依存ピクセル）の略で、dipとも呼ばれたりします。この単位のおかげで、多種多様なAndroidデバイスの画面サイズ・解像度において、（ある程度は）同じ表示ができるようサポートができるわけです。
dpにまつわる単位としては、デバイスそのものの画面解像度になるpx（pixel）、1インチ幅にどれだけのドットがあるかを示し、hdpiとかxxxhdpiとかの汎用密度に分類することのできるdpi（dots per inch）、そして本題のdp、フォントサイズの指定に使うsp（scale-independent pixels：スケール非依存ピクセル）等が挙げられます（pt/mm/inもありますがここでは一旦見なかったことにします）。px/dpi/dpについては
px = dp * (dpi / 160)
の関係が成り立ちます。画像リソースのサイズには
- mdpi → 1倍
- hdpi → 1.5倍
- xhdpi → 2倍
- xxhdpi → 3倍
- xxxhdpi → 4倍
のような倍率で指定していましたが、これはあくまで上の式「dpi / 160」の形式化をしたものであるというわけで、実際に1dpが各端末のデバイス上で厳密に何pxになるか、という意味だと必ずしもこれらには一致しないと認識しています。
また、spはdpと似たような挙動をしますが、「ユーザのフォントサイズ設定」に応じて表示サイズに倍率がかかるので、アクセシビリティ等を観点に含めればより重要な値となります。
では、「小さい端末」ってなんだろう
少し前の話かもしれませんが、Androidの画面サイズ（16:9のとき）は一般的にはdpで表記すると 360 x 640dp であるという話でした。
例えば、Sony XPERIA XZの画面サイズをdpで表記するとたしかにxxhdpiで360 x 640dpです。
一方、物理的に小さい端末のはずのRakuten Miniも計算してみるとxhdpiでこちらも360 x 640dpになりました。
つまりRakuten Miniは「（デザイン的には）別に小さい端末とは言えない」という話になります。
逆に大きいデバイスで考えてみると、Nexus 6/Nexus 5Xあたりを皮切りに360dpより横幅の大きい端末が出てきました。
例えばPixel 3を見てみると、xxhdpiですが px = dp * (dpi / 160) の (dpi / 160) に相当する部分が2.75になるので、392 x 786dpという画面サイズが得られます。
以下のサイトを見ていると、特に最近出た端末なんかは (dpi / 160) の値が整数ではなくなってきた感じがあるので、そこらへんが大きな変化なのかなぁと思います。
ちなみに1/1.5/2/3/4ではなくなったら「mdpi/hdpi/xhdpi/xxhdpi/xxxhdpiはもう用済みなのか」というとそういうわけではなくて、やはり画像リソース（非Vector Drawable）を使用する際は適切なリソースサイズを配置する必要があるので依然大事な値だと考えています。
しかしここまで360dpより小さい値が出てこなかったので、「もしかしてAndroidにおいて小さい端末というのはもう存在しないのでは…？」というとそうではありません。Android 7.0以降から、ユーザ補助 > 画面サイズで画面をスケールさせることができ、これを最大にしたとき、画面の横幅が320dpになります。ある意味ではこれがAndroidにおける「小さい画面」の回答であり、どの端末でも適用可能なので、横幅320dpでの表示には気を使う必要がありそうです。
逆に縮小して画面幅を広げることも可能で、そちらでは領域不足の表示崩れ…が起きるわけではないとは思いますが、実際にどのように表示されるかはチェックしておくべきでしょう。
エンジニアとしてどう気をつけるべきか
Android Studio 4.0からLayout Validatorが搭載されました。これによって、実際に手元にデバイスが揃っていなくとも、擬似的に様々な画面での表示を検証することができます。少し話はそれますがフォントサイズ設定や色弱の方向けの比較表示も可能なので、アクセシビリティ的な対応を行う意味でも使いこなすメリットは大きいでしょう。
また、adbコマンドを使ってWindowManagerを操作し、実機上で表示がどのように変化するか検証することも可能です。これらによって「320dp以下ではどうしてもレイアウトの実現が厳しい」という話になるのであれば、 sw320dp のような設定修飾子を付与したdimens/layoutディレクトリを用意することで、各マージンやレイアウトそのものを切り分けるのが対策として考えられそうです。
終わりに
久々にdpやAndroidの画面周りについてガッツリ調べてみたのですが、「以前よりもめんどくさくなってない…？」という感じでした。Pixel 3でdp -> pxの倍率がxxhdpiだから3…というわけではなく2.75になっているのは言われてみると「確かに…」という感じにはなるんですが普通に見落としていたので、デザイナーさんにわかりやすく説明しようと思う過程で自分の勉強にもなりました。dp周りはAndroidの画面デザイン・画面実装の基礎だと思うのでしっかり把握して認識を合わせてきれいに無理なくレイアウトできるようになりたいものですね。
References
- https://qiita.com/nein37/items/0a92556a80c6c14503b2
- 【Android】いまさら聞けないdp入門 | Qiita
- https://developer.android.com/training/multiscreen/screendensities?hl=ja
- https://developer.android.com/about/versions/nougat/android-7.0-changes.html?hl=ja#screen-zoom
- https://developer.android.com/guide/topics/resources/providing-resources.html?hl=ja#AlternativeResources
- アプリリソースの概要 - 代替リソースを提供する | Android Developers
余談：お前飲酒したの？
資料を書いているときは流石に飲酒していないんですが、構想中は横浜ビールを、資料の執筆中は軽井沢高原ビールのワイルドフォレストを頂きました。どちらも好きなビールなので美味しかったです！ ところでリモート環境下になって途端にお酒に弱くなったんですが僕だけでしょうか。
わいわいたとランチに行った話と最近の雑談
この記事は whywaita Advent Calendar 2020 8日目の記事です
まずはじめに
ぼくとわいわいたさんの関係をクソ雑に話すと「同じ会社のひと」です。入社年度が違ったりしますが同い年なのでタメ語で話しています。年下の先輩とか同い年の後輩とか、妙に言葉遣いに迷ったりしますよね。そういうやつです。
本題
せっかくなのでネタ作りにわいわいたさんとランチに行きました。渋谷パルコの地下にあるわいわいたさんがよく行くお寿司屋さんです
副題
中身がうすすぎるので普段わいわいたさんとどんな雑談をしているのか思い出してみました。
イベントの配信の話
雑談の半分以上を占めている気がします。ATEM MiniのようなHDMIスイッチャーからマイク、カメラみたいな配信機材の話をしていますね。 実際にオンライン勉強会でのイベント配信の準備を手伝ってくれたりもしたので、カメラやスイッチャの構成やOBSの設定とかをやいのやいの話したりしているみたいです。
通信回線の話
お家のネットワークやモバイルのネットワークの話をしています。僕はお家の回線には詳しくない（人に聞きながらVDSLをIPv6 + IPoEにした程度）ので、モバイルの話になると興味がわきます。
散財の話
お互い特に考えもなくガジェットを購入してしまうので、あれを買っただこれを買っただを話しています。散財額で勝敗を最近決めていましたが、よく散財している方がいいんですかね。
slackの発言数を眺める
僕のtimesチャンネルとわいわいたさんのtimesチャンネルの発言数を見てはきゃいきゃいしています。発言数をみて勝っただ負けただ言っている様子が見えますが、一体なんの基準によって決まっているのかはわかりません。
まとめ
ぼくとわいわいたさんはそこそこ雑談をしていることがわかりました。仕事で疲れた時に息抜きをするのは大事ですね。 あとわいわいたさんのよく行くお寿司屋さんは美味しかったです。ちょっといいことがあった時にお昼の贅沢としてまた行こうと思いました。
電動昇降デスクFLEXISPOT E3が届いたので組み立てRTA（Solo Any%）して使ってみた
どーも、どくぴーです。
とあるご縁でFlexiSpotの電動昇降デスクをレビューする機会を頂き、実際に実物が届いたので組み立てて使ってみました。
ちなみに送っていただいたのはFlexiSpot E3というモデルで、天板は140cm x 70cm x 2.5cmのMaple 角丸にしました。
2020/10/24現在でキャンペーンをしていて、ノートパソコンスタンドがもらえるみたいですね。天板はFlexiSpotさんが用意しているものの以外に自分で用意してDIYすることもできます。 脚（？）のスペックとしては
- 耐荷重100kg
- 対応天板幅110cm-180cm
- 昇降スピード38mm/sec
- メモリ、アラーム機能搭載
という感じです。脚を左右に広げたり縮めたりできるので、それで天板の幅に合わせるという感じですね。
届いた
当然組立前の状態で届くのでこの時点で家に入らないんじゃね？みたいな心配はありません。ただし35kgあるので姿勢が悪いと多分腰をやるので気をつけましょう。 届いた後にFlexiSpot組み立てRTA（Solo Any%）の前走者の知り合い何人かに「何用意したらいい？」「何を気をつけたらいい？」って聞いていたら
- 電動ドリルが無いと死ぬ。錐で穴を開けたら大変な思いをします（1敗）
- 重いなーと思って頑張ってたら床を傷付けるのでタオルを敷きます（1敗）
- 動かす時は床にタオルや布を敷いて引っ越し屋の要領で頑張る
- 時間はかからんが1日潰すくらいの気持ちでやれ
等、ありがたいお言葉を頂いたので、とりあえず電動ドリルを用意しようと思いサクッと購入しました。買ったのは他のFlexiSpot組み立てレビューでも上がっていたBOSCH IXO5のドリルビットセットです
漢ならマキタっしょみたいな頭の悪い思考があったのですが、やはり高いし用途として十分そうだったので今回はmicroUSBで充電できたりコスパの良さそうなこちらを採用です。車好きとしてはBOSCHは多少滾るものがあります。
組み立てた
まずは一旦天板を床に引っ張り出します。天地逆転で組み立てて最終的にひっくり返して配置するイメージです。ちなみに初手で写真を撮り忘れたのでここはガバです。 FlexiSpotさん公式の天板を使う場合はすでに一部に穴が空いていて、それには操作パネル用の穴が長辺側に空いています。ひっくり返した際に手前に来るように、その穴を奥向きに置くと吉でしょう。
一旦天板を引っ張り出したら脚側の箱を開けてネジが揃ってるか確認します。微妙に一品足りないとか無いと中途半端に組み立てたデスクが鎮座することになるので、念には念を入れます。大体現場猫レベルの勢いで「ヨシ！」ってなるので大丈夫そうだったら説明書を読み出します。使うネジがABCで袋分けされていてわかりやすいなって思いました。
そしたらまずは脚の部分と天板の裏に這わせるビームを組み立てていきます。この時点ですでに重いので早速作業には要注意です。ネジ締めは歪んだり、バランスを崩さないように対角線上のネジをまずは軽く締め、全部終わったらそれぞれをしっかり締め切る対角締め・増し締めで落ち着いてやっていきます。
その後も勢いよく足を組み上げ、天板と合体していきます。天板には釘ネジで固定するのですが、天板に穴の空いていない部分にも釘ネジを打つ必要があるので、ここでドリルを使って下穴を開けるのが必要でした。説明書通りに入れると22本釘ネジを打つ必要があるので、一番時間がかかる工程です。
その後は配線したり電源ユニットや操作パネルと言った昇降に必要な部品を組み付けていって、組立自体は完了です。
ひっくり返して配置した
多分一人で組み立てる場合はもっとも危険なポイントです。40-50kgサイズのものをひっくり返すので床や壁に傷をつけるくらいならまだしも、怪我をしかねないので慎重に進めました。 とりあえず手前に半回転回してみたんですが、重心が足元側に来るのと天板の奥行きが70cmと大きめなのでとにかく立ち上げにくくて、「詰んだのでは…？」って5分くらい遠い目をしていました。
腰を覚悟しながら頑張ったら無事に立ち上がったので、完成です。
後は壁側に頑張って押し込んで、電源をつないで高さを最大にしてみます。超高い。
ひたすら上下してみて、満足したら後は前の机にあったものをいい感じに再配置したらFlexiSpot組み立てRTA（Solo Any%）完走です。朝10時から始めて13時位に終わったのでタイムはだいたい3時間でした。
完走した感想（激ウマギャグ）
組み立てそのものはガンプラみたいなプラモデルや自作PCみたいな組み立てよりよっぽど簡単でした。家具の組み立てとか初めてだという人も説明書だけで十分理解できると思いますし、幸いYouTubeなどに公式さんや色んな人が組み立てている動画を上げているので、コツみたいなのもなんとなく分かると思います。ただしとにかく部品一個一個が重くて大きいので作業スペースの確保と床や壁の保護と工具（電動ドリルドライバー）は必須だと思いましょう。僕は大丈夫だったのですが組み付けが悪いと昇降が動かなかったりするらしいです。ネジの締め方（対角締め、増し締め）、配線のコネクタの挿抜確認はしっかりやっておくと後で確認したりする手間がなくなるので、落ち着いて時間をかけて組み立てましょう。 基本的にはやっぱり重いので一緒に誰かが作業してくれたほうが楽で安心なのは間違いないです。
一週間ほど使ってみて
間違いなく快適になりました。もともと使っていたのがそんなにしっかりしたデスクというわけでもなかったというのが大きいですが、全然揺れることもないので剛性は本当に高いと思います。FlexiSpotさんの天板が厚さ2.5cmあるので、マイクアームやディスプレイアームなんかのクランプで留めるような部品も安心して固定できます。
肝心の昇降部分についても、メモリが3つあるので僕は「作業用」「スタンディング用」「レースゲーム（ハンドルコントローラ）用」に割り当てました。昇降時のモーター駆動音なんかも静かで、深夜に動かすのも安心ですし、昇降速度も速いので高さを変えるのも億劫にはなりません。アラーム機能はスマートウォッチやアクティビティロガーで「同じ姿勢になっていたらアラートを鳴らす機能」を使ってる人にはあまり意味がないかなぁとは思うのですが、特に自宅での作業でそういうの付けずに集中するような人には気分転換や座り疲れの予防に良さそうだなって思いました。まだ組み立てて一週間ほどしか使っていない上に、この一週間は諸事情でリモートワークではなく出社していたために使い倒せているわけでもない状態なのですが、長く付き合うデスクはいいものを入れると捗る気がしてきますね！
チラシの裏の話
昇降時にケーブルを繋いでいる機材が落ちる
PCの裏にHDMIセレクターやHDMIセパレータ等のHDMIケーブルを束ねてつなぐ物があり、一番高くしたときにケーブル長としては余裕があるのを確認していたのですが、引っかかったりして机の上からずり落ちてしまうケースがあったのですが、セレクター等に地震用の滑り止めシートを貼り付けたら解決しました。
梱包がすごく厳重
DroidKaigiのスタッフとかをしている都合で梱包を良くするのですが、届いて箱を開けて真っ先に出た感想が「梱包のガチ具合がすごい」でした。天板の角を保護する部分の素材がダンボールのみじゃなくて発泡スチロール、ウレタン混合になってたり、脚もすごく分厚いダンボールとウレタンを使いながら隙間がないように配置されてて、すごかったです。
昨今リモートワークが盛んなので環境を構築した話
どーも、どくぴーです。
昨今ご時世的にリモートワークがお盛んですね。 自分も絶賛リモートワークなうなので、お家で開発したり、ビデオ会議したりしています。 暗い話題が多くなりがちですがそんなにめげずに散財の証…じゃなかった、リモートワークでも諸々効率化させるために用意したものの話をしましょう。
家具
そもそも大事ですね。上京した当時から使ってる7000円くらいのどこのブランドかわからない140x70cmのデスクと6000円くらいのドウシシャのオフィスチェアを使っています。 そんなに困っていないんですが、会社のローテーブル勢の人とかを見ていると「腰が大変なことになった」とかなんとかでAKRacingのゲーミングチェアだったりを揃えようとしているのを見ると座る環境って大事なんだなぁと思います。会社の椅子、メッチャいいんだなって思います。
140cmもあれば余裕なのでは、とは思っていたのですが、デスクの左半分に
こんなのが装備されていて、半ばレースゲーム専用のスペースと化しているので、生きているスペースは実質半分ってところです。
モニタ
@puhitaku から譲ってもらったEIZO FORIS FS2332を使っています。足を引っこ抜いてVESAマウントにこれまた貰い物のモニターアームを装着して使っています。 PCの出力以外にもPS4，Switch、自作PCの出力にも使っているので4入力のHDMIセレクターを挟んでいます。ゲームの録画も出来るようにAVerMedia AVT-C285もキャプチャ後段に刺さっていますがそれはまた別の話。
開発環境
会社/自宅のMacBook Proを付け替えながら使っています。会社にいるときは自作キーボードのMint 60とMagic TrackPadを使っているのですが、今の机だとディスプレイを体の前には持ってこれそうにないのでMBP側をメインスクリーンとして扱っています。なのでキーボードもMacBook Proの筐体キーボード。
自作キーボード環境に戻そうとすると、多分ディスプレイもWQHDのやつにしてデスクもゲーミングスペース排除して広くして…ってなりそうですね。
ミーティング環境
リモートで仕事する以上、ミーティングもリモートなのでビデオ通話が中心になります。Slack CallとかGoogle MeetsとかZoomとか。 なんにもこだわらなければMacBook ProについてるFaceTime HDカメラとマイクで十分じゃんってなるのですが、多分部屋の照明の影響で自分だけ顔色が悪くなったり、声が通りにくかったりすると言われたりしたので、もうこうなりゃヤケだと言うことで大散財をしました。
音声周り
なんか入門ド定番らしいということでマランツプロフェッショナル MPM-1000とヤマハ AG03を購入しました。
今となってはAmazonを見ても軒並み売り切れているらしいですね。音声周りはだいぶ改善したみたいです。ノイズが小さくなったって言われたんですが、指向性があるのも多少あるのかなマイク自体はオーディオテクニカのAT2020とかが競合製品なので、そっちを狙うのはありかも。これを書いている時点ではまだサウンドハウスには在庫があるみたい。
ちなみに、カメラにマイクが映り込むと「え？YouTuber？」とか「ガチじゃん」とか言われて若干インパクトが出てしまいます。気をつけましょう。
MPM-1000はXLRケーブルで接続するので、PCに接続するためにはXLR端子を挿せるオーディオインターフェイスが必要なので、合わせてヤマハAG03を買いました。USBに直に接続できるMPM-1000Uというモデルもあるので、本当はそっちを買えば安く済んだはず…。AG03側でボリュームを調整したり出来るので咄嗟にミュートにしたいときとかはAG03のつまみをイジイジしています。
これらの機材はDroidKaigiのセッション録画環境構築のために購入したので実際買ったのは3月の頭とか、そんなころでした。気づけばセッション録画では使うことなく、ビデオ通話で使うことになるとは…。
動画周り
こうなりゃいっそビデオ通話の映像も画質を良くしたいぜということで、カメラ周りも機材を調整しました。カメラ自体は手持ちのSony α7IIIとSEL24105Gを使っています。
どう見ても明らかにオーバースペックなんですが、今家にある機材がこれしかなかったので登板です。LUMIX G8/G9 Proとかもあるんですが、諸事情で会社で使ったあと置いているうちにリモートワークに突入してしまったので回収が必要そう…。
カメラからはHDMI出力で映像を引き回してPCに取り込んでいます。PCにHDMI出力を取り込む際にはHDMIキャプチャが必要なので、そこはj5Create JVA04を使うことにしました
JVA04 USB Type-C ゲームキャプチャーjp.j5create.com
HDMIパススルー対応のHDMIキャプチャです。HDCPは非対応なので、Macの出力とかを直接つなぐと映像を拾えなかったりします。カメラのHDMIとかPS4、Switchは行けるのでゲーム配信もできそう。
こちらもDroidKaigiのセッション録画環境のために購入したものでした。ちなみに2入力を実現するためにHDMIキャプチャはもう一台、I-O DATA GV-HUVCを持っています。
その他
リングフィットアドベンチャー
運動不足不可避だったので、仕事がスイスイ進んだ日はリングフィットアドベンチャーをしています。まじで買えないゲームなんですが、奇跡的にNintendo Storeのダウンロード版を1月に購入できたのがラッキーでした。
今は運動強度25前後でワールド13でやっています。レベリングをしていたわけじゃないんですが、クエストこなしながらガシガシリングコンを押し込んでたらレベル130になってしまったので多分推奨レベルとかガン無視してて、RTA動画を先に見てリングコン押し込み走法を覚えるんじゃなかったという気持ちです。バンザイスクワットが超きつい。
あと、気分的に柔軟体操もはじめました。もともと体がめちゃくちゃ硬いのでなんとかしたかったんですが、少しずつだけど効果がある実感をしています。
サンコー おひとりさま用超高速弁当箱炊飯器
これもリモートワークが始まったから買ったものじゃないんですが、秋葉原をぶらついてたらたまたまサンコーレアモノショップの店頭に置いてたので買いました。
気軽に1合までならサクッと米が炊けるので、炊きたてご飯が簡単に味わえます。おかげで自炊が捗る。
買っちまったツイートをしたらサンコーレアモノショップの中の人に補足されてTwitterでパスタ茹でたり炊き込みご飯炊いたりしてる人がいるのを教えてもらいました。
部屋の大掃除
東京一人暮らしだと部屋はせいぜいそんなに広くないので散らかってると気が滅入って仕方ないのでリモートワークが始まった週の週末に大掃除を決行しました。おかげさまで足の踏み場ができてハッピー。リングフィットアドベンチャーもはかどっています。
そんなこんなで
デスクの上はこうなりました。はっきり言って汚いので整理したい気持ちがあります。
ここまで揃えるとゲーム配信とかもできちゃうよなぁという気持ちになってきたので、レースゲームかリングフィットアドベンチャーをやってる様子をTwitchなりで流してもいいんじゃなかろうかみたいな顔になってきました。マイクもあるしPodCastとかもしたいななんて、色々妙なことを考えています。
飲酒プログラミング失敗ログ
本記事は飲酒プログラミングAdvent Calendar 2019の記事です。
TL;DR
- 飲酒プログラミングに失敗しました
- お酒は飲みました
- 部屋の掃除をしました
はじめに
去年もやったんですが飲酒プログラミングをしました。金-土の今日くらいまで飲酒しながらプログラミングして進捗を出そう的な。
実際飲酒してプログラミングしてある程度進捗を出したんですが特に成果が出なかったのでただのログになります。
ログ
2019/12/6（土）
21:00-22:00 ランニングする
22:00-22:30 シャワーを浴びる
22:30-25:00 満を持して飲酒プログラミング
25:00 就寝 .
とりあえず夜も遅かったのでセブンイレブンのしたらば（プレーン）をつまみにサッポロ黒ラベルをキメました。
作業内容としては新規Androidプロジェクトのひな形づくりです。そんなに規模が大きくないプロジェクトを対象に1からDaggerを組み込んだMVP構成のプロジェクトテンプレートっぽいのを作り出しました。
ココ最近本業とかでDagger周りでハマることが多くてふええって顔になってたんですが Android Dagger codelab やMaster of Daggerを読みながらDagger周りの再勉強をしてたんですがようやく仲良くなれた気がします。詳しくは別の記事にでも書く…つもりです。
2019/12/7（日）
08:30 起床
08:30-09:30 支度
09:30-10:30 歯の定期検診で歯医者に
10:30-11:30 朝食
11:30-12:30 DroidKaigiの資料構想練り
12:30-13:30 昼食
13:30-17:30 部屋の掃除
17:30-18:30 夕食
18:30-20:00 DroidKaigiの資料で使うサンプルアプリの開発を始めた
20:00-今 このブログを書いている
飲酒タイミングは夕食時にもう一本のサッポロ黒ラベルでした。
全ての敗因は部屋の掃除をしたことです。部屋がきれいになったので反省はしていません。
ちょくちょく出てきてますがDroidKaigi 2020に登壇することになりました。40分も話すのは初めてなので緊張してます…。
Android Studioを使ったデバッグ周りの話をするのでデバッグにお悩みの方はぜひお話しましょう :pray:
考察
飲酒するとパフォーマンスが落ちることがわかりました。当たり前ですね。
アルコールが抜けてきたのでちゃんとプログラミングします。すいませんでした。
Bonfire Android #5 レポートを書くのが遅れたらJetpackに大リリースが来てた
はじめに
開催からだいぶ空きました（忙しくて時間がとれなかった…）が、8/19に開催されたBonfire Android #5 に参加してきました
なのでレポート的に各発表をまとめようと思います。今回のテーマは「Jetpackとサービス」ということで、Jetpackに関連する話題を中心とした発表が揃っていました。
navigationを見据えたリファクタリング~マルチモジュール化を添えて~
木内 啓輔さん (@fei_kome) ◆ ヤフー株式会社
実装・運用されている期間が長いアプリをマルチモジュール化・navigation componentsをする際に考えられていることについてお話されていました。
マルチモジュール化自体、近年トレンドになった話題で（僕はDroidKaigi 2018でマルチモジュールに関する話を初めて聴いて、そこから話題になったと感じているだけかもしれないです）、やはりそれ以前からずっと開発されていたアプリは「マルチモジュール化されることを想定していない」「モジュール分割に耐えうるような依存関係・設計ができていない」という状態にあると思っています。
それを踏まえて、実際にマルチモジュール化を実現するためUI-Presenter間の相互依存を解消するための腐敗防止層的なInterfaceを作ったりすることでnavigation componentの導入を視野に入れた切り分けを実現するといったリファクタリング過渡期の実装tipsについて紹介されていました。
マネーフォワードMEにおけるJetpackの活用事例
syarihuさん (@syarihu) ◆ 株式会社マネーフォワード
syarihuさんが以前他で発表された内容も織り交ぜながら、マネーフォワードMEがどのようにAndroidXを始めとするJetpackの導入を行っていたのか、導入から1年経って何が変わったのかについてお話されていました。 マネーフォワードMEでのJetpackの導入は
- 手入力画面のリファクタ、設計変更を含めたJetpack導入
- 月額課金機能へのPlay Billing Library導入
- LiveData、ViewModel、Lifecycleを用いてBillingViewModelを作り、どの画面でも課金機能を作りやすい状況に
- 入出金履歴画面へのBottom Navigationの導入
- 複数の遷移元が存在し複雑になってしまった更新リクエストをRxJavaのBehavingProcessorとLiveDataを用いることで簡単に扱えるように
という感じだったそうです。導入を始めてからはおおよそ1年とのことで、古い機能の刷新と並行して行う機会が多かったようで設計適用のためのリファクタではなく、多くの部分に導入を進めることができたことや、このJetpackの導入、設計変更によってテストの記述効率の向上を果たせたとのことでした。
Paging Libraryでのアイテムの更新
釘宮 愼之介さん (@kgmyshin) ◆ 合同会社DMM.com / CTO室エバンジェリストチーム
Paging Libraryを使って、チェックボックスの操作といったリストのアイテムの更新をどのようにUIまで反映させるかについてお話されていました。 基本的な実装手順からよく躓くポイントとして
- アイテムがアップデートされない
- ItemRepositoryに新しいデータを保存する
- DataSourceをinvalidateして再取得を走らせる
- 更新はしたもののスクロール位置が急に最初に戻る
- initialzeKeyがPageKeyedDataSourceを使ってる限りnullになるから
- 対策としてRoomを使う
- DatabaseとDaoを作ることでDataSource周りをよしなに作ってくれる
- マイグレーションが大変、このためだけにDBを持ちたくない場合はInMemoryでも使える
- Roomを使わなくてもできる
- BoundaryCallbackを扱うItemDataProviderを自前で実装することで実現できる
- Repositoryがページ単位を、DataSourceがItem単位を扱うと考えて実装する
それぞれのやり方についてサンプルも公開されているので、気になる方は確認してみましょう。
Roomとコルーチンと私
荒木 佑一さん (@yuichi_araki) ◆ Google
Room 2.2.0-alpha02でのアップデートとして様々な機能が追加されましたが、その中でもCoroutines Flowを主眼において解説されていました。
Room自体、2.1.0でsuspend functionに対応して、coroutineで書くとメインスレッドでinsert等のメソッドを実行してもsuspendしてバックグラウンドに行ってくれる、というような解釈をしてくれるようになっており、更に Transaction アノテーションを付与することでcoroutinesが取り消されたり、エラーになったときに処理全体を取り消したりできる機能が追加されています。
Room 2.2.0では、これらに加えてCoroutines Flowに対応しており、Coroutines Flowの特徴である
- コールドストリーム（cf. Channel：ホットストリーム）
- アクセスされるまで処理が実行されない遅延評価
- コンテキスト保持
- Dispatcherを指定できる
- 例外透過
- .catchで例外を補足できる
といった恩恵を受けることができ、DB操作を監視した処理ができるようになるなどしています。
また、RoomのDaoの内部実装でどのようにCoroutinesを実行しているかという話や、Roomが非同期実行の際にトランザクション、スレッドを適切にハンドリングしていることについても言及されていました。
jetpackのNavigationと関連UIコンポーネント
樫村 実紅さん (@k_miku) ◆ ヤフー株式会社
www.slideshare.net
開発されているアプリにNavigationを導入された際のことについてお話されていました、ヤフーニュースアプリ、一つの大きい改修を行う際には一つ新しい技術にチャレンジすることを掲げているそうですね。
各画面の遷移をなめらかにするために1-Activity / n-Fragment構成を実現すること、Fragmentの遷移管理の負担を下げること、トレンドへの追従を目的としてNavigation導入を行ったということで、実際に導入する中で躓いたポイントとして
- ActionBarと連動をさせようとすると仕様に合わない
- Resource XMLに定義した文字列のタイトル反映はできるが画像やEditText、動的な文字列といったものは出せない
- 結果としてActionBarと連動させることは諦め、各画面でActionBarをそれぞれ操作することにした
- 画面遷移時のアニメーションのカスタマイズ
- NavigationUI#setupWithNavControllerを使う際、デフォルトで指定されているアニメーションしか使えない
- OnNavigationItemSelectedListenerを自前で作り、その中でNavOptionsをbuildすることでカスタムのアニメーションを設定した
- 画面遷移時に遷移以外の操作を行いたい
- 遷移したというユーザ行動等のログを取る必要がある
- 同様に、OnNavigationItemSelectedListenerを自前で作り、その中でItemのIDをみてログを送信した
という手段とをって解決されていました。
あまりにも遅筆過ぎた結果Jetpackが大リリースしてた
完全に怠慢の限りなのですが、イベント後しばらくたった9/5のタイミングでJetpackに大きなリリースがやってきて、いろんなコンポーネントがstableになったりしました。Room 2.2.0もrc1になったりしています。
先日あったca.apk #8で発表された資料を引用するのですが、Activityも1.0.0でFragmentのバックハンドリングが onBackPressedDispatcher で行えるようになっていたり、Activity（1.0.0） / Fragment（1.1.0）でLayout ID Constructorが追加され、layoutのリソースIDを引数に渡すことでsetContentView / onCreateViewを省略できるようになったり、いろんなトピックスが起きています。
Androidに限らず、この手のアップデートがすごい勢いで行われるのでBonfireを始めとした勉強会で新しい知識を気軽に知ることができるのはすごい素晴らしいと思います。インプットした知識を現場に還元し、また新たなアウトプットを生み出せるといいなと思いました。
最後に
Bonfire Androidを主催してくださったヤフーさん、本当にありがとうございました。レポートを書くのが非常に遅くなってしまい大変申し訳ありませんでした… :bow:
Bonfire Android #4 に参加してきた #yjbonfire
久々に勉強会に行ってきたブログを書きます。
Yahoo! Japanさん主催のBonfire Android #4にブログ枠として参加してきました。
Bonfire Androidでは毎回テーマを決めてYahoo! Japanさん内外から登壇されるのですが、今回は「UI」がテーマと言うことで、5人のデザイナー・エンジニアの方がチームでのデザイン手法、UI開発といったトピックを発表されていました。本記事では、各発表を振り返っていこうと思います。
Yahoo!乗換案内アプリでのデザイナーの役割について（山浦優樹さん）
エンジニア・デザイナーそれぞれ二人づつで開発されているというYahoo!乗換案内アプリでのデザイナーの立ち回りについて話されていました。初期はデザイン工数等の関係で以前はAndroid/iOSで共通のデザインを使っていた状況からMaterial Designを始めとしたAndroidデフォルトなデザインへ寄せていく中で、デザイナーがMaterial Design、Theme、Design Support LibraryといったUIに関わるAndroidの技術に対しての知識を持っていったことや、実際にLayout XMLをデザイナーが編集する、というようにデザイナーができることを大きくしていく中で
- デザイナーはUIの磨き込みに集中できるように
- エンジニアは実装に集中できるように
という2つの環境を実現するためのデザインフローについてのお話をされていました。
一方で、実際にデザイナーがAndroid Studio上でLayout XML/Drawable XMLといったResourcesを作るという役割の拡大について、自分で触ることでエンジニア以外には得にくかった「アプリデザインではプラットフォームごとにどのパーツが使えるかを知れる」というメリットはあるもののそこに踏み込むことの難しさについても触れられていて、HTML/CSSでのWebDev領域のようなハブとなれるプレイヤーを立てることでうまく回るのでは、と述べられていました。
”Material Designの変化”の中でアプリエンジニアができること（中村恵太さん）
2014年6月に公開されたMaterial Design Guidelineにおよそ4ヶ月で準拠したラクマのフリル時代から今の新ラクマまでのMaterial Designまでの変遷に触れて、初期のMaterial Designのメリットとして
- ユーザエンゲージメントにとどまらないメリットがある
- 開発効率
- エンジニアのデザインへの意識が上がる
- デザイナーとデザインについて議論する際の共通言語になれるかも
という点があるものの
といったデメリットが有ると述べられていました。その後Material DesignにLaunch ScreenやBottom Navigationといった新しいコンポーネントや2018年5月に公開されたMaterial Design Guideline 2.0によってブランド表現が柔軟になったこと、変化を継続していくデザインシステムになったことを説明し、その中でアプリエンジニアは何ができるのかということで
- 変化に柔軟（であろう）というエンジニアの強みをUI領域にも持ち込む
- 個人的にはアンテナを張っている、新しい情報へのリーチが早い、ということかなと解釈しています
- Material Designのキャッチアップをただの情報共有ではなく課題解決目線として提案していく
- 何が表現できて、どうプロダクトに取り込めて、結果何が解決できるのかという具体的な提案
というアクションの提案をされていました。この提案のためにSketchプラグインであるMaterial Theming Editorをエンジニアが提案のためのツールとして用いることでデザイナーの改善イメージのサポートに役立てようと動いていることが興味深かったです。
自由度の高いアプリ内UIを実現するためのKARTE SDKの仕組み（中間亮彬）
トラッキングや分析、アプリ内メッセージやプッシュ通知を行うことができるKARTEのアプリSDKについて、特にアプリ内メッセージについての実装面でのお話をされていました。アプリ内メッセージへのアプローチとしてフォーマットに従って配信するネイティブ実装とHTML/CSSを管理画面上で記述するWebView実装があること、カスタマイズ性を重視してWebViewでの実装を選択したことについてまず触れ、実際にKARTE SDKの内部構成やその中でのデータフローといった技術的な要素によってWeb・アプリ双方で同じUIとしてアプリ内メッセージを提供することを実現することについてお話されていました。
UI改善に繋がるエンジニアの立ち回り（瀬戸優之さん）
デザイナーとやり取りができる、工数の巻き戻しができる人を対象として、必要な知識がデザイナーとエンジニアで重なる部分があるUI改善のためにエンジニアはどう立ち回るべきか、というお話をされていました。
まず普段からエンジニアができることとして、デザイナーがアンテナを張っていても情報を得にくい部分である、
- 環境について
- ProgressDialogが非推奨になっている、というような実装レベルでのUIパーツの使用可否
- Material Design Components（MDC）についての情報
- そもそもAndroidXが必要
- ではプロダクトがいつからAndroidXに対応して、いつからMDCを使えるようになるのか
- 実装について
- 工数見積
- Material Design Guideline 2.0で定義されたExtended FABがボタンで作れること
- ダイアログがダイアログを出すのような二重表示ができないこと
というような情報を共有することで早い段階での気付きにつなげていくという点に触れ、そのためにコミュニケーションポイントを増やす必要があり、頻度が高いコミュニケーションほどコストが掛かるものの、Material Design Guideline輪読会のような定期的な会を行うことでMaterial Designの知見や共通認識・AnimationやComponentといった環境や実装の話といったコミュニケーションを実現するという提案をされていました。また、エンジニアが気にするべきデザインのチェックポイントとして
- 画面回転や横レイアウト
- 直しにくい、工数的に厳しい場合は画面回転・横レイアウトを許可しないという手もある
- Empty Status
- オフライン時挙動
- キャッシュを出すのかそもそも動作を止めるのか
- マルチウィンドウ、縦長ディスプレイ
- そもそも非対応にするのか、UIの要素を伸ばすならどこか
- コードレベルでのチェックポイント
- エラー通知
- try-catch / onErrorのフィードバックが存在しているか
- 仕様が複雑化していないか
- 異常に複雑な実装は仕様からすでに複雑になっているかもしれない
- エラー通知
- ユーザ目線でのチェックポイント
- 操作の手数
- エンジニアが操作に疲れるならユーザも疲れる
- 大体1画面3操作を意識する
- RAILモデルを利用した動作速度ベンチマーク
- 操作から100ms反応が無いとユーザは困惑する
- 1000msかかるとユーザの離脱率が上がる
- 操作の手数
という点を挙げられていました。日頃の仕事でも考えているものもあれば、全然気にしていなかった事もあって、すぐ効果が出るわけではないものの、これから意識して実践することによって少しでも改善に貢献していきたいと思いました。
エクストリーム・プログラミング開発におけるUIテスト〜ライブコーディングを添えて（飯島彩輝さん、松田悠吾さん）
LEAN XPを導入しているヤフオクチームでの実際の開発事例をライブコーディングを交えて説明されていました。
何を作るか？を絞るLEANとどうやって作るか？を絞るXPを組み合わせたLEAN XPにまず触れ、その中の要素としてペアプログラミング、テスト駆動開発、ユーザーストーリー（とストーリーポイント）を始めとしたものがあること、実際にヤフオクチームで実践しているPivotal Tracker上でのユーザーストーリー管理からのじゃんけん見積もりによるストーリーポイントを決定することによるチーム内での認識齟齬の解消、片方がテストを先に組み、片方が実装を行うペアプログラミングによるテスト駆動開発をライブコーディングしていく中で
- 同じ画面を見ながら開発で早い段階でミスに気づくことができる
- どういう実装をチームの人がするのかをリアルタイムで見れることでレビューコストを減少できる
- テストコードが仕様書と化すので、開発へ大きく時間を割くことができる
- ユーザーストーリーの実装ごとにリリースを行うことで効果を都度確認することができる
という利点を挙げられていました。また、実際の導入効果として、
- シナリオテストの失敗率の大幅な減少
- 手戻りが減った
といった点をお話されていました。
後記
登壇者の方々、主催、運営のYahoo! Japanさん、本当にありがとうございました！
ちゃんとレポートをしたのは久しぶりなのですごく疲れました。
エンジニア懇親会というと、寿司！ピザ！みたいなイメージなのですが、今回の懇親会はすごくおしゃれな感じでした。 きっきパイセン（ @dnc_pop30 ）に聞いてみたところ、ツイートに上げた写真を使っていいと言われたので飯テロ写真を置いておきます（ありがとうございます）。
😇😇😇 #yjbonfire pic.twitter.com/nKRRXNvK9M
— きっき(｢・ω・)｢ (@dnc_pop30) March 1, 2019