あなたは Android Architecture Component をどう思いますか?

ある人々のTwitter上の会話。ザクッと翻訳サービスを利用して眺めてみます。

Frankly, the expectation is that all applications of a considerable size already use some form of DI. Thus providing yet another way to pass dependencies via context is an overkill. All "non-DI" facilities are just gimmicks/workarounds for cases when there is no DI.

率直に言って、かなりの数のアプリケーションがすでにDIを使用している。したがって、コンテキストを介して依存関係を渡すためのさらに別の方法を提供するのはやり過ぎです。すべての「非DI機能」は、DIがない場合のギミック/回避策にすぎません。

On Android this sadly isn't the case. We seem to relish in bad architecture.

It's either "Why do I have to pass an executor/scheduler/dispatcher? So much boilerplate!" or "Why can't I test on the JVM? This library is poorly designed!"

Maybe KEEP-87 will save us from ourselves?

Androidでは、これは悲しいことではありません。悪いアーキテクチャーで大喜びしているようです。

「executor / scheduler / dispatcher を渡す必要があるのはなぜですか? かなりのボイラープレートです。」、「なぜJVMでテストできないのですか?このライブラリは適切に設計されていません。」

多分KEEP-87は私達を私達自身から救うのだろうか?

👉 [Kotlin] KEEP87 brings compiler-driven dependency injection without frameworks : androiddev 

On unrelated note. (disclaimer: I'm not an Android developer) I have a feeling that something is broken in testing or architecture approaches here. I've been writing huge (1M+ LOCs) UI apps for more than a decade and never had to use either DI or statics to make them testable.

無関係なメモについて。 (免責事項:私はAndroidの開発者ではありません)何かがここでテストやアーキテクチャのアプローチで壊れていると感じています。私は10年以上にわたって巨大な(1M + LOC)UIアプリを書いてきました。そしてそれらをテストするために DI や statics を使う必要は決してありませんでした。

Android never had architecture guidelines and the docs encouraged doing all the wrong things to make the tutorials easy. Basically equivalent to writing everything in main(). Even now almost all of the architecture offerings treat symptoms of this legacy and not the disease.

Androidはアーキテクチャのガイドラインがなかったので、チュートリアルを簡単にするためにすべての間違ったことをすることをドキュメントを奨めてきました。基本的にmain() ですべてを書くのと同じです。現在でも、ほとんどのアーキテクチャがこの遺産の症状を治療していて、疾患を治療していません。

👉 Roman Elizarov on Twitter: "@JakeWharton Frankly, the expectation is that all applications of a considerable size already use some form of DI. Thus providing yet another way to pass dependencies via context is an overkill. All "non-DI" facilities are just gimmicks/workarounds for cases when there is no DI." / Twitter 

みなさんはどう思っていますか?

Roman Elizarov
@relizarov
Team Lead @JetBrains, working on @Kotlin coroutines and libs, sports programming/ICPC, concurrency & algorithms, math/quantitative finance; formerly @Devexperts

👉 Roman Elizarov (@relizarov) / Twitter 

Jake Wharton
@JakeWharton
Opinions expressed here are my own, not those of my company. They made me write this because I complain about Inbox going away so much.

👉 Jake Wharton (@JakeWharton) / Twitter 


Kotlin で FizzBuzz の適当な記述

くだらない企業面接で今だに出題されてホワイトボードに記述させられるという。

👉 Fizz Buzz - Wikipedia 

ゴルフほど可視性を無視しないとしたら、ここらが適当なところと思う。





👉 Kotlin Playground: Edit, Run, Share Kotlin Code Online 

紙にアルファベットで書かせる企業もあるという。

👉 Kotlin で FizzBuzz 


【公式 2018-05-07】Android Pie のバージョンシェア がひそかに 10%超えている件

前回の2018年10月からひさびさの更新となります公式 Android Developers のこのページ。

Android Pie の割合が10%を超えたようです。

しかし、更新日付が以前のままです。

ダッシュボード  |  Android Developers

英語版を見てみます。

Distribution dashboard  |  Android Developers

「日本語版の更新日付部分」のみが古いまま。

このページに関しては、どうやら英語版のページを確認したほうがよさそうです。



Android Pie から始まる「ナビゲーションバー」の混乱と操作の覚え方

Android Q beta3 で感じる Navigation Bar (ナビゲーションバー) の方向性

「ナビゲーションバー」というのは、画面下部にある3つのボタン群のことです。

きっと、端末で最も頻繁に使うボタンたちです。

何ができるか

デフォルトで5つの操作ができます。

- ホーム画面の表示
- アシスタントアプリの起動
- 戻る
- アプリドローワー(一覧)の表示
- 最近使ったアプリの一覧表示

ボタンの表示され方

表示のされ方はいくつかあります。

戻る + ホーム + 履歴
(Oreoまでのスタイル)

戻る + ホーム
(Pixel Launcherスタイル)

表示なし (隠れているなど)
(ベンダーカスタムなスタイル)

これは、

- OSバージョン
- 機種
- ナビゲーションの設定
- 端末の状態

によっても変わります。

OSのアップデートや機種変更で表示されるボタンがいきなり変わってしまい操作が混乱します。

覚え方

覚えておくのは、

「右ボタンがなければ(アプリ履歴切り替えは)、中ボタンのスワイプ系操作(上・右)で行う。」

ということぐらいしかありません。

右ボタンが表示されている場合

左ボタン
タップ → 戻る

中ボタン
タップ → ホーム画面の表示
長押し → アシスタントアプリの起動
上スワイプ → アプリドローワーの表示*

右ボタン
タップ→ アプリ履歴表示(切り替え)

右ボタンが表示されていない場合

左ボタン
タップ → 戻る

中ボタン
タップ → ホーム画面の表示
長押し → アシスタントアプリの起動
上スワイプ → アプリ履歴表示*
上ロングスワイプ → アプリドローワーの表示
右スワイプ → 直前のアプリ表示* (P/Qで微妙に異なる)
右スワイプ&ホールド → アプリ切り替え選択* (Pのみ)

ややこしいです。

分かりやすくまとめることができません。

将来は、左の戻るボタンがiPhone のように無くなる噂もあったりして今後も混乱は続きそうです。

👉【Android Pie】「通知」設定のシンプルな考え方
👉 Android Q beta3 で感じる Navigation Bar (ナビゲーションバー) の方向性
👉 Android Pie opens up recent apps customization for third-party launchers
👉【Android Pie】ナビゲーションバー の ホームボタン を ピル型 にする方法
👉 Android 9 Pieの新「ナビゲーションバー」 普及なるか? - ITmedia Mobile
👉【公式 2018-05-07】Android Pie のバージョンシェア がやっと 10%超えている件


「Unresolved reference: R」と出る

謎。

androidx か?

Unresolved reference: R - Twitter検索 / Twitter

AGP3.3 - Twitter検索 / Twitter

AS最新版へ更新でケリがつく。

IDEもチャラく頻繁に切り替える時代?

JetBrains Toolbox で Android Studio の Stable/Beta/Canary が同時に管理できる?