Android Qでは戻るボタンがなくなる…? | ギズモード・ジャパン
Pの実装状態を見る限り明らかに左方向は意図的に開けてるよな。

ピルボタン(ホームボタン) の 使い方 と アプリ履歴 の 一括削除 【Android Pie】
しかし、いまやボタン一つの操作方法多すぎじゃね?
Gboard 日本語 12キー 左右のカーソルキーを使ってすばやく上下移動する方法
いちいち
「ボタンをみたら上下左右にグリグリ」
やってみるとかなあ。
Android Qでは戻るボタンがなくなる…? | ギズモード・ジャパン
Pの実装状態を見る限り明らかに左方向は意図的に開けてるよな。

ピルボタン(ホームボタン) の 使い方 と アプリ履歴 の 一括削除 【Android Pie】
しかし、いまやボタン一つの操作方法多すぎじゃね?
Gboard 日本語 12キー 左右のカーソルキーを使ってすばやく上下移動する方法
いちいち
「ボタンをみたら上下左右にグリグリ」
やってみるとかなあ。
Gboardで単語を登録しても変換候補に反映されないときは、
キーボードの設定
↓
単語リスト(ユーザー辞書)
↓
学習した単語を削除
です。



どうやらキーボードアプリによっては(Gboardなど) これまでの入力内容によって自動作成された候補文字列が優先的に変換候補に表示されるようです。
自動作成される変換候補は今現在では意外と使えないので削除してもいいと思いますけども。
それでもダメな場合は、Gboardのキャッシュを削除すると良いです。
「設定」
↓
「アプリ」
↓
「Gboard」
↓
「ストレージ」
↓
「キャッシュを削除」


Android OS デフォルトの単語リスト登録画面よりは、「顔文字/絵文字辞書 単語リスト」が便利です。

顔文字や絵文字もガツガツ登録できます。
Retrofit の coroutine 対応が進んでいるようです。
Jake Wharton's retrofit2-kotlin-coroutines-adapter has been the go-to solution for bridging the coroutine world with Retrofit for a little while. But now, a much-anticipated PR has finally been merged, officially bringing coroutine support to Retrofit 2.
Retrofit meets coroutines - zsmb.co
SpaceX-API とか公開されていたのですね。

r-spacex/SpaceX-API: Open Source REST API for rocket, core, capsule, pad, and launch data
https://api.spacexdata.com/v3/rockets

対応する最小限のデータクラスを作って、試してみましょう。
data class Rocket(
val id: Int,
@field:Json(name = "rocket_name")
val name: String
)
val retrofit = Retrofit.Builder()
.baseUrl("https://api.spacexdata.com/v3/")
.addConverterFactory(MoshiConverterFactory.create())
.build()
val api = retrofit.create<SpaceXApi>()
create() は reified type が使えるようになってます。
JSONのシリアライズはお好みのものを。
そして、interface を書いていきますが、
ここを戻り値に別に見てみます。
interface はこれまでと同じ記述。
interface SpaceXApi {
@GET("rockets")
fun getRockets(): Call<List<Rocket>>
}
受け側の3つの例。
runBlocking {
val rockets: List<Rocket> = api.getRockets().await()
rockets.forEach(::println)
}
runBlocking {
val rockets: List<Rocket> = try {
api.getRockets().await()
} catch (e: Exception) {
println("Network error :[")
return@runBlocking
}
rockets.forEach(::println)
}
runBlocking {
val response = api.getRockets().awaitResponse()
if (response.code() == 200) {
response.body()?.forEach(::println)
}
}
結果はすべて同じ。
Rocket(id=1, name=Falcon 1)
Rocket(id=2, name=Falcon 9)
Rocket(id=3, name=Falcon Heavy)
Rocket(id=4, name=Big Falcon Rocket)
これまで非同期処理時に必要だった コールバック や enqueue の記述は必要ありません。
受け側の記述を変化させることで、Exception や レスポンスコードを拾うことができます。
suspend を使うことでさらに直感的に書けます。
interface SpaceXApi {
@GET("rockets")
suspend fun getRockets(): List<Rocket>
}
runBlocking {
val rockets = api.getRockets()
rockets.forEach(::println)
}
結果。
Rocket(id=1, name=Falcon 1)
Rocket(id=2, name=Falcon 9)
Rocket(id=3, name=Falcon Heavy)
Rocket(id=4, name=Big Falcon Rocket)
List<Rocket> に対して Call や Deferred のようなラッパーは必要ありません。
Response を拾います。
interface SpaceXApi {
@GET("rockets")
suspend fun getRockets(): Response<List<Rocket>>
}
runBlocking {
val response = api.getRockets()
if (response.code() == 200) {
response.body()?.forEach(::println)
}
}
結果。
Rocket(id=1, name=Falcon 1)
Rocket(id=2, name=Falcon 9)
Rocket(id=3, name=Falcon Heavy)
Rocket(id=4, name=Big Falcon Rocket)
最も実用的で簡潔な記述と思われます。
Kotlin で記述するにしても、多くの記述が可能となりそうです。
RxJava他ライブラリを利用しての非同期実装を含めると様々となります。
ネット上で検索するにも自分の環境や好みに合った記述を探すのにも時間がかかることになり混乱もありそうで。
Jakeも今後はメンテしないと思われます。

ちなみに、これらの話は今現在はSNAPSHOTで進行中です。
以下でどうぞ。
repositories {
maven { url "https://oss.sonatype.org/content/repositories/snapshots" }
}
dependencies {
implementation "com.squareup.retrofit2:retrofit:2.5.1-SNAPSHOT"
}
なんとなく面倒なのでスクリプトで。
USBで接続のあと #5555 で待たせて再起動する。
「restart」なので、kill-server → start-server は不要。

adb tcpip 5555
IPアドレスをコマンドラインから取得。
ip="$(adb shell ip route | awk '{print $9}')"
そのIPにWiFi接続。
adb connect $ip
ついでに、開発時には邪魔なスリープもOFFに。
adb shell svc power stayon true
How to prevent an android device from entering sleep (via adb command shell) - Stack Overflow
connect_via_wifi.sh
#!/bin/sh
adb tcpip 5555
sleep 1
ip="$(adb shell ip route | awk '{print $9}')"
adb connect $ip
adb shell svc power stayon true
adb devices -l
端末内 adbd の TCPモード(#5555)が起動している限り再接続が可能。

なので、USB接続なしの状態でも
IPの目処つけて 「adb connect」 でどうぞ。
~ $ adb devices
List of devices attached
~ $ get-oui -v
Renaming ieee-oui.txt to ieee-oui.txt.bak
Fetching OUI data from http://standards-oui.ieee.org/oui/oui.txt
Fetched 4084734 bytes
Opening output file ieee-oui.txt
25968 OUI entries written to file ieee-oui.txt
~ $ sudo arp-scan -l
Interface: en0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.0.1 8a:af:ec:9c:91:08 BUFFALO.INC
192.168.0.2 dc:23:76:3d:9b:75 HTC Corporation
192.168.0.3 d0:27:82:f5:e8:2a AzureWave Technology Inc.
192.168.0.8 8c:85:00:14:89:d1 Murata Manufacturing Co., Ltd.
192.168.0.4 a2:37:e3:12:9a:88 HTC Corporation
192.168.0.6 33:28:6d:29:7b:72 Google, Inc.
~ $ adb connect 192.168.0.4
connected to 192.168.0.4:5555
~ $ adb devices
List of devices attached
192.168.0.4:5555 device
初回の、USBケーブルなしでTCPモードを起動できないのはセキュリティ絡みでか。
ADBオーバーネットワークでWiFiで複数端末を一括接続する
Android Devices Being Shipped with TCP Port 5555 Enabled - DEV Community 👩💻👨💻
Coroutine で Channel 辺りをウロウロと。
あれ?

This declaration is experimental and its usage should be marked with '@kotlinx.coroutines.ObsoleteCoroutinesApi' or '@UseExperimental(kotlinx.coroutines.ObsoleteCoroutinesApi::class)'
調べてみる。
From the point of usage `ObsoleteCoroutinesApi` is just like experimental. The different is in intent. When API is experimental it might change or might graduate as is. For obsolete API we already know that there are problems with designs that will force us to deprecated this API in the future when we have a better replacement.
Right now there is no replacement for channel operations, so you have no choice but continue using them. However, we plan to replace them with mechanism based on lazy/cold streams (#254) in the future, which will get you much better performance.
What is the recommended approach for @ObsoleteCoroutinesApi #632
Google翻訳で。
使用の観点からObsoleteCoroutinesApiは実験的なようです。 違いは意図しています。 APIが実験的なものである場合、それは変更されるか、またはそのまま卒業するかもしれません。 時代遅れのAPIについては、より良い代替品があるときに将来的にこのAPIを非推奨にするような設計上の問題があることはすでにわかっています。
今のところチャンネル操作に代わるものはないので、あなたには選択肢がないがそれらを使い続けることができる。 ただし、将来的にはレイジー/コールドストリーム(#254)に基づくメカニズムに置き換える予定です。これにより、パフォーマンスが大幅に向上します。
@ExperimentalCoroutinesApi
→ 将来的には、変更される or そのまま。
@ObsoleteCoroutinesApi
→ 設計上の問題がある。
→ 今現在、代替えはない。
→ 将来的には非推奨。
アンダースコアがついてるのはそゆこと?
チャンネル周りは、今は「様子見」がいいのでしょうね。