【Android Pie】Google Digital Wellbeing を使う

Android Pie にあげたら、入れてみましょう。

Android 9 Pie 使ってみた

今はまだベータプレビュー版の Digital Wellbeing。

テスターとしての利用です。

煩わしい通知を制限したり、それとマナーモードの関係をアプリごとに設定することができるようになります。

- アプリ別の起動回数・通知回数・時間の把握
- アプリ別の通知設定
- アプリ別のマナーモード設定
- アプリ別利用時間タイマーの設定

「通知がこない」、「通知がブロックできない」など自分の利用イメージに合わせて設定できずに逆に混乱しません?

通知が表示されない とかどうせブロックの設定だろ! → 原因「フィルター」

本当に「幸福度」が上がるのは、触ってみて何回かの仕様確認の後になると思います。

Android 9 Pie 使ってみた
【Android Pie】ナビゲーションバー の ホームボタン を ピル型 にする方法
【Android Pie】Google Digital Wellbeing を使う
【Android Pie】Auto-rotate (自動回転) OFF のときの挙動
【Android Pie】使いやすくなった音量設定
【Android Pie】スクリーンショット取得→編集 は「電源ボタン長押し」から


JetBrains の IDE が全て半額! 急げ!! 当然 Intellij IDEA もだぞ?

急げ! あと数時間しかないぞ!

Don’t miss the JetBrains Friendship Day special offer — all individual tools for developers at 50% off! #JetBrainsFriends

持ってる知り合いを探して、クーポン発行をお願いする、なのか?!

詳細はよう分からんがお得なはず!!


【DIY】700円でつくる Magic Keyboard/Trackpad2 向け Mac Book Pro 13インチ型縦配置の枠

横に並べて置くことを想定して設計されていますよね、Magic Keyboard/Trackpad2。

Magic Keyboard - 英語(US) - Apple(日本)

MacのためのMagic Trackpad 2(シルバー)を購入 - Apple(日本)

Keyboard の厚さが 4.1-10.9mm、
Trackpad2 の厚さが 4.9-10.9mm。

元々 Mac Book Pro 13インチ から移行した人にとっては、手の横移動が億劫に感じます。

かといって、縦に並べておくと誤操作連発でイライラすぎ。

この厚みの差が問題なんですよね。

探してみると、こんなのありますが。

BulletTrain eXpress Keyboard Platform | Indiegogo

商品詳細 Crispy Backboard 2

なんだかな...。

ホームセンターの木材加工サービスを利用して作ることにします。

材料

Mac Book Pro 13インチの寸法を雑に測っておきます。

これに近い雰囲気で縦に並べて置くことにして考えます。

縦に並べて置くには、厚さが、6.8-10.9mm の板が良さそう。

ホームセンターに行ってみると、300x300x7mm の木板が、328円であったのでこれにしました。

プラスチック板もあったのですが、今回は木製にします。

設計

ホームセンター内の加工サービス受付で、簡単な図面を書きます。

「直線で切り落としのみ」ということで、途中でカット作業は止めることができないそうなので、切り落とした部材をパズルのように並べることにします。

数分でカットされてきます。

1カット80円ということで、320円でした。

組み立て

とはいっても並べるだけです。

7mmなので木工用ボンドで接合しても強度が弱いので、その場合は薄い何かの上に並べて貼り付ければいいでしょう。

できあがり

手前の板は不要に思っていたのですが、パームレストのようにあると腕が疲れません。

とりあえず、まあいいか。

使いながら改良していこうと思います。

→ A Mac Book Pro style Wooden Dock for Magic Keyboard and Trackpad 2


Android Architecture Components: Room の Migration で IllegalStateException

データを移行せずに捨ててしまうのなら、以下でいいのですが。


Room.databaseBuilder(context, RepoDatabase.class, DB_NAME)
    .fallbackToDestructiveMigration()
    .build();

きっと捨てることができませんよね。

テーブル定義を変更しながら、データを移行しますよね。


Room.databaseBuilder(context, RepoDatabase.class, DB_NAME)
    .addMigrations(FROM_1_TO_2)
    .build();

static final Migration FROM_1_TO_2 = new Migration(1, 2) {
    @Override
    public void migrate(final SupportSQLiteDatabase database) {
        database.execSQL("ALTER TABLE Repo
                         ADD COLUMN createdAt TEXT");
        }
    };

database.execSQL()でSQLをベタに実行しながらデータを別テーブルにRENAME後、CREATE→INSERT→DROP というかんじでスキーマを変更していますが。

すると、こんなのに遭遇します。

java.lang.IllegalStateException: Room cannot verify the data integrity. Looks like you’ve changed schema but forgot to update the version number. You can simply fix this by increasing the version number.

データベースのバージョンナンバーは上げることは、まあ上げるとして、それでもインデクスなどうまく意図通りに移行できてない場合があります。

データモデルにアノテーションで記述した「Room が利用しようとしているスキーマ」と、Migration部分にベタ記述した「SQLiteのスキーマ」が合致しないといけません。

また、最近のAndroidでは、.dbファイルが、OS上で取り回しづらく、実態を把握しづらかったりします。

Roomが認識しようとしているテーブルスキーマは以下で書き出すことができます。


android {
    javaCompileOptions {
        annotationProcessorOptions {
            arguments = ["room.schemaLocation":
                         "$projectDir/schemas".toString()]
            }
        }
    }
}


"tableName": "Repo",
"createSql": "CREATE TABLE IF NOT EXISTS `${TABLE_NAME}` (`id` INTEGER NOT NULL, `name` TEXT, `url` TEXT, PRIMARY KEY(`id`))"

モデルクラスに記述したアノテーションのRoomが認識している状態(expected)をSQLで書き出してくれます。

これと、MIGRATION部分のベタSQL(found)を比較すると、意味が分かってきます。

複数フィールドに対してのUNIQUE なインデクスなど、公式ドキュメントとは違う内部的絶賛更新中な処理な部分など、書き出してみると先に進むことができます。


Android Studio のビルドの体感速度を上げる IDEAプラグイン「Nyan Progress Bar」

プログレスバーのカスタマイズプラグインです。

こういうことです。

 

蓄積されていくイライラは少しずつでも解消していきたいものですよね。

Nyan Progress Bar :: JetBrains Plugin Repository